REMARKS 

Concerning the Specification. 

Paragraph 1 of the Official Commiinication objects to the disclosure due to two 
informalities. These informalities have been corrected in the substitute specification. 
Concerning the Drawings. 

Paragraph 2 of the Official Communication indicates that the drawings filed on 
25 May 2001 are acceptable subject to correction of informalities noted in the Notice of 
Draftperson's Patent Drawing Review. Included in this response is a Transmittal of 
Corrected Fomial Drawings by which Applicants have corrected the informalities noted 
by the Official Draftsman. 
Concerning the Claim Rejections. 

At the mailing of the Official Communication, claims 6-68 were pending with the 
Office setting forth grounds rejecting each of these claims. The claims have been 
amended, mostly to reformat the claims, but in some instances, to fiirther place the claims 
in condition for allowance. As a result of the amendment to the claims, claims 6-18, 22- 
46 and 48-73 are pending in the application with claims 19-21 and 47 having been 
withdrawn without prejudice and claims 69-74 having been added as new claims. The 
applicant submits that the amendments along with the accompanying arguments place the 
pending claims in condition for allowance. 

Four dependent claims have been withdrawn and one independent claim (claim 
16) has been converted to a dependent claim. Six dependent claims have been added. 
The cost that would be associated with adding six dependent claims at $9 per claim for a 
small entity would be $54. However, withdrawing four claims and converting claim 16 



Page 28 of 37 



to a dependent claim should result in a $79 credit. Thus, applicant submits that no 
additional fees are required at this time. 

Paragraphs 3-4 set forth rejections for various claims xmder 35 U.S.C §102(e) as 
being anticipated by U.S. Patent No, 6,449,601 to Friedland et al. (Friedland), For the 
reasons that follow. Applicants respectfully traverse these grounds for rejecting the 
claims identified in numbered paragraph 4 of the Official Conraiunication. 

With regards to claim 6, the applicant respectfiiUy submits that the claimed 
invention is not fiiUy disclosed in Friedland and thus, is in condition for allowance. 
Claim 6 has been amended to remove the "means-plus-fimction" language. 

Auctioneer is in control . The Office will appreciate that the claimed invention 
enables the auctioneer to remain in control of the auctioning event. This aspect of the 
invention is not described, suggested or taught in Friedland. More specifically, the 
various components of the claimed system, including the clerk system, cooperate to 
integrate a remote bidding audience with the onsite bidding audience of a live auction, 
while still allowing the auctioneer to remain in control of a live auction event. The 
auctioneer being in control of the auction event is a key element for the integration of the 
remote bidders into the live auction. The auctioneer needs to have control over which 
bids are accepted, which bids are rejected, when the bidding is going to be closed, when 
the next lot is put on the block, when the lot is moved into a pre-sold state, etc. Li 
addition, the auctioneer needs to have the fireedom to work the remote and onsite 
audiences to push bids to their maximum level, play bidders off of each other, and 
generally apply the psychology of the bidding process. For the auctioneer to maintain 
such control, the various events (i.e., the transition from a bidding state to a sold state) 
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must be conducted under the control of the auctioneer rather than some external force. If 
such transitions are controlled by external events, the auctioneer is stripped of some level 
of control. 

Friedland teaches a time-based transition system that greatly limits the 
auctioneer's control of the auction event. Throughout the Friedland reference, the 
system is described as a time-based transition system. For instance, Friedland states that 
"at some specified time interval, the lot transitions to either the state "pre-bid" 206 via 
transition 208 or the "open for bidding" state 210 . . Col. 6, line 19. Friedland also 
states that "after another interval of time, the lot transitions from the pre-bid state to 
either the open-for-bidding state 210 via transition 216 or the state "pass" . . ." Col. 6, 
line 29. Again, Friedland states that "a lot in the presold state will be sold to the current 
highest bidder unless a higher bid is received within some time interval." Col. 6, line 
60. Other similar references can be found at col. 6, line 55, line 56 and line 64, and col. 7 
line 18. 

Thus, in Friedland, state transitions from the pre-bid state to the sold state can 
occur totally autonomous of the auctioneer because such transitions are time-based. 
Thus, in Friedland the auctioneer is not in control of when the auctioning for a particular 
lot begins and ends. 

In the present invention, the system is operated imder the direction or control of 
the auctioneer. An item is not sold until the auctioneer makes that determination. The 
auctioneer is not subject to the timing constraints described in Friedland, and in fact, if 
the auctioneer so desires, he or she can delay a particular lot for as long as he or she 
deems is necessary, or abruptly end the auctioning. The Office will appreciate how this 
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control enables the auctioneer to respond to the onsite and remote audiences, play the 
audience members off of each other, and generally control the auction event. Friedland 
cannot provide such control to the auctioneer because it is strictly a time-based transition 
system. Thus, Friedland cannot possibly describe, suggest or teach the control aspect of 
the present invention because it explicitly strips the auctioneer of such control. 

The Clerk System. Furthermore, with regards to claim 6, the Office will 
appreciate that the invention recited in claim 6 includes a clerk system and a bid system. 
The applicants respectfully submit that Friendland does not, among other things, 
describe, suggest or teach the use of the clerk system of the present invention. 

In general, Friedland describes distributing live auction-related content over the 
Intemet. The live auction-related content is generated by and exchanged between remote 
auction bidders and a human proxy for the remote auction bidders. The human proxy is 
physically present in the audience at a live auction and is nothing more than one more 
member of the onsite live auction audience. More specifically, the human proxy sits in 
the live auction audience with a laptop computer on which are composed auction status 
updates that are based solely upon the human proxy's personal observations of the live 
auction activities. The human proxy distributes the composed auction status updates 
from the laptop computer via the Intemet to the remote auction bidders. The remote 
auction bidders may send auction bid instructions via the Intemet only to the human 
proxy's laptop computer. The human proxy must then physically retrieve the remote 
auction bidder's bid instructions from the laptop and then must physically indicate the 
remote auction bidder's bid to the live auction auctioneer in the same traditional manner 
that onsite live auction bidders do and have historically done. As a result, the auctioneer 



Page 31 of 37 



does not have any information indicating the identity of the remote bidders, is not able to 
interact with the remote bidders, and during the auction, carmot distinguish between the 
local bidders and remote bidders other than the fact that one of the local bidders is 
operating a laptop computer. 

The clerk system operates to process both onsite and remote auction bids. It 
should be noted that the clerk system has the ability to accept and reject auction bids 
either automatically, imder the direction of the auctioneer, or under the control of a clerk 
being directed by an auctioneer. This is very different from the capability of the hxmian 
proxy described in Friedland, Friedland does not describe, suggest or teach the element 
of a clerk system that can accept or reject auction bids and the human proxy taught in the 
Friedland does not and cannot perform the functions of the applicants' clerk system. 

One illustrated embodiment of this capability includes a BID INCREMENT BAR 
that the clerk can select to solicit bids. Independent from this fimction the clerk can also 
accept bids from the floor or from remote bidders by selecting the FLOOR BED button or 
the REMOTE BID button respectively. Friedland does not describe, suggest or teach 
this capabihty. In contrast, the human proxy described in Friedland decides which 
remote bids shall be submitted to the auctioneer and only then does the auctioneer have 
decision making power related to any particular remote bid. 

Integration of Remote Bidders. Furthermore, the Office will appreciate that 
Friedland teaches a distribution of the auctioning status to remote bidders whereas the 
present invention is focused on an integration of the remote bidders into the live auction. 
For instance, in Friedland^ the use of a human proxy prevents integrating the remote 
bidding audience and the auctioneer. The auctioneer in Friedland has no idea who is 
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providing a remote bid because the bid is entered to the floor by the human proxy raising 
his or her hand and bidding on behalf of the remote bidder. It is clear that in Friedland, 
no aspect of the remote bidder's personality is presented to the auctioneer and the 
auctioneer is unable to exploit the psychological attributes inherent in an auction 
atmosphere. However, the integration provided for in the present invention allows the 
auctioneer to work both the onsite and remote bidding audience by reading the audience 
and individuals, playing the individuals off of each other, and drawing larger bids for the 
items being auctioned. Because Friedland is simply a distribution system - the human 
proxy distributes status information to the remote bidders rather than integrating them 
into the audience - this level of integration is not described, suggested or taught. 

In addition, Friedland does not describe the integration of the local bidders with 
the remote bidders as disclosed in the present invention. In the present invention, the 
clerk system instantaneously processes auction bids from onsite auction bidders and from 
remote auction bidders. This aspect of the present invention is illustrated in the 
embodiment of the "Delete Bid" function. When the clerk system enters the acceptance 
of a bid, the next acceptable bid increment is determined. If remote bids are pending, the 
clerk system can automatically accept a pending remote bid. However, if the auctioneer 
awards the bid to an onsite bidder rather than a remote bidder, the clerk can select the 
"Delete Bid" function to delete the automatically accepted bid. This is a level of 
integration that is not described, suggested or taught in Friedland, and in fact, could not 
be implemented in the Friedland system as described because Friedland does not 
describe, suggest or teach such a clerk system. 
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Marquee System. In claims 7-10 and 13, the element of a marquee is included. 
The marquee operates to further integrate the remote bidders into the live auction. The 
marquee is used to display the identity of the remote bidders so that the auctioneer can 
interact with the remote bidders. In addition, through observing the marquee, the onsite 
bidders can have a level of confidence of the identity of the remote bidders. 

Therefore, the applicant submits that claim 6 is allowable over the cited 
references. Furthermore, independent claims 7-10, 12-16, and 61-63 each recite the clerk 
system. Thus, the applicant submits that each of these claims is in condition for 
allowance and are not described, suggested or taught in the cited references. 

Integration of Audio . With regards to claim 8, the applicant respectfiiUy submits 
that the claimed invention is not fiilly disclosed in Friedland and thus, is in condition for 
allowance. Claim 8 has been amended to remove the "means-plus- function" language. 
Claim 8 includes the element of an audio system that provides a live audio feed to the 
remote bidders. Friedland does not describe, suggest or teach this element. The only 
related reference in Friedland is that a remote bidder can listen to a live broadcast of the 
auction via various communication mediums. However, Friedland does not describe a 
mechanism for such a function to be integrated into the bidding system. In the claimed 
bidding system, this functionality is a complicated and integral component of the system. 

Therefore, the applicant submits that claim 8 is allowable over the cited 
references. Furthermore, independent claims 9, 14, 16, 61 and 62 each recite the audio 
system. Thus, the applicant submits that each of these claims is in condition for 
allowance and are not described, suggested or taught in the cited references. 
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The remaining claims are dependent claims that either depend directly or 
indirectly from one of these independent claims. The applicant respectfully submits that 
the Office's rejection of the independent claims should be removed and that these claims, 
as well as the dependent claims are in condition for allowance. 

Paragraphs 5 and 6 set forth rejections of various claims under 35 U.S.C 
§ 103(a) as being unpatentable over Friedland, 

Paragraph 7 sets forth rejections of various claims under 35 U.S.C § 103(a) as 
being unpatentable over Friedland in view of U.S. Patent Number 6,415,269 awarded to 
Dinwoodie (Dinwoodie), 

Paragraph 8 sets forth rejections of various claims under 35 U.S.C § 103(a) as 
being unpatentable over Friedland in view of U.S. Patent Number 6,006,201 awarded to 
Berent et al. {Berent), 

Paragraph 9 sets forth rejections of various claims under 35 U.S.C § 103(a) as 
being impatentable over Friedland and Dinwoodie, and further in view of Berent, 

Applicant respectfully submits that each of the rejections set forth in paragraphs 
5-9 has been overcome in the arguments presented with regards to the rejections in 
paragraphs 3-4. However, the applicant addresses an additional point with regards to 
dependent claims 1 1, 18, 67 and 68. 

In these claims, the element of a data mining capability is recited. Claims 1 1 and 
18 recite the data mining capability for processing and analyzing the onsite and remote 
auction bid history for each item auctioned. Claims 67 and 68 recite the abiUty for the 
remote auction bidders to access the information retained by the data mining means. 
None of the references cited by the Office describe, suggest or teach the capability for the 
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remote bidders having access to such information. Thus, the applicant respectfully 
submits, that in addition to the previous arguments pertaining to the claims, that for at 
least this reason, claims 11, 18, 67 and 68 are not described in the cited art, are in 
condition for allowance, and requests the Office to allow these claims. 

New claims 69-70 have been added to the application. These claims more clearly 
recite the ability for the remote auction bidders to access the data mining means to review 
the bidding history for particular items. Support for these claims is found on pages 50-5 1 
of the original specification. 

New claims 71-72 have been added to the application. These claims recite the 
ability for the bidding system to include multiple bidding engines. Thus, depending on 
the particular structure of the auction, different bidding engines could be utilized to drive 
the auctioning process. Support for these claims is found on pages 32-46 of the original 
specification. 

New claim 73 has been added to the application. This claim recites the ability to 
ensure the integrity of the bidding information by limiting the streaming audio 
transmission. 

New claim 74 has been added to the application. This claim recites the 
integration of the audio capabilities into the bidding device, hence the audio capabilities 
become an integral component of the entire system. 

The new claims do not add any new subject matter nor should they require an 
additional search by the Office. It is respectfully requested that these claims be allowed 
by the Office. 
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Conclusion 

For all these foregoing reasons, applicant respectfully requests the Office to 
reconsider the Friedland, Dinwoodie, and Berent references in light of the applicant's 
remarks set forth above, and to thereafter recognize the clear limitations of the disclosure 
and teachings of the Friedland reference and the patentable distinction of the claims of 
the present application over these references, either taken alone or in combination, and 
then allow all claims of the application now pending over the prior art references of 
record. 

Thus, the applicant respectfully submits that the claims as amended, and the 
argxoments proposed for rejection traversals place the claims in condition for allowance 
and respectfully request the Office to move this case to allowance. 

Further, applicant respectfully requests the Office to call the applicant's attomey 
if there are any questions or amendments that can be handled through an examiner's 
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REMOTE BIDDING SUPPLEMENT FOR 
TRADITIONAL LIVE AUCTIONS 

CROSS-REFERENCE TO RELATED APPLICATIONS 

This application claims the benefit of co pending U .S. p rovisional application for 
5 patent having been assigned serial number 60/207,030, and filed on May 25, 2000. This 
application also incorporates by reference the computer program listing appendix 
("System Software") Copy 1 and Copy 2 containing the files having the dates of creation 
and size in bytes set forth on pages 70 to 7 3 hereo f m Exhibit A . The remote bidding 
suppl e m e nt for traditional liv e auctions of th e pr e s e nt inv e ntion is a softwar e based 
10 product that provides th e capability for a us e r to instantan e ously int e ract with and e njoy 
the emotion and enthu s iasm of a traditional, liv e auction (vi e w it e ms for sal e , vi e w liv e 
bidding, hear the auctioneer calling bids, view the activities of the onsite participants, 
malc e bids, buy it e ms) fi'om a position that is physically r e mot e fi'om th e liv e auction. 

TECHNICAL FIELD 

15 The present invention relates to the field of converging real-life events and remote 

access through network communications and, more particularly, to a remote bidding 
supplement for traditional live auctions that provides the capability for a user to 
instantaneously interact with and enjoy the emotion and enthusiasm of a traditional, live 
auction (i.e., view items for sale, view live bidding, hear the auctioneer calling bids, view 

20 the activities of the onsite participants, make bids, buy items) firom a position that is 
physically remote fi'om the live auction. 
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BACKGROUND OF THE INVENTION 

Traditional-style auctions are ignoring a significant market— ^the physically 
remote purchasers who will purchase an item without being physically present to kick the 
tires, feel the smoothness of a vase, hear the roar of a diesel engine or authenticateing an 
5 ancient item. 

Currently, there are two types of remote auction systems. The first type of remote 
auction system has no "live" auctioneer and the entire bidding audience must be 
connected to the network or system. In this case, the network computer or server acts as 
the auctioneer, accepting bid values fi"om the connected audience with associated time 
10 stamps based upon bid receipt by the server. Each bid is either accepted or rejected by 
the server; and-the bidder (sometimes the entire audience) is notified of its acceptance or 
rejection. All of the items for sale in this type of auction are generally available for the 
entire duration of the auction and each item has a specified end time after which no bids 
will be accepted. 

15 The second type of remote auction system is much like the first; however, it may 

or may not have a "live" auctioneer. The main difference firom the first type of remote 
auction system is that each item for sale is not available at the same time; rather, the 
auction moves fi-om item to item and depending upon the bidding activity and upon either 
the server's or "Uve" auctioneer's choice, the item is sold and the event moves on to the 

20 next item on the list. 

A disadvantage of remote auctioning svstems is that tlie participating bidders are 
not engrained into the excitement and energv of the live auction. From the perspective of 
an auction company, this can have a significant impact on the success, or the earnings, of 
the auction company. Many books have been written about the psychology of the auction 

25 floor and the best auctioneers are talented in the science of reading a crowd and 

individuals, playing them off of each other, and drawing larger bids for the items being 
auctioned. Thus, there is a need in the art for a technique to integrate remote auctioning 
systems into the real life envirormient of the auction floor. There is also a need in the art 
to allow the auctioneer to extend his or her talents beyond the auction floor and *Nvork" 

30 the crowd of remote bidders as well as the local bidders. There is also a need in the art to 
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integrate remote bidders into a live auction setting in a manner that does not alienate or 
result in giving an advantage to either the local bidders or remote bidders. 

SUMMARY OF THE INVENTION 

The present invention allows for prospective auction bidders to participate both in 
5 person as well as in a remote capacity. The present invention enables an existing 
traditional-style auction company to utilize technology that allows an auction to be 
conducted in the traditional style, generating the emotion and enthusiasm in the local 
audience, leaving the auctioneer in tetal-control of the sale, while providing the 
opportunity for other bidders to "attend" the auction event remotely (e.g., via the 

10 Internet), sharing the same emotion and enthusiasm as the local audience and 

participating in the bidding process without disadvantage, just as if those physically 
remote bidders were sitting in the local auction audience. 

The present invention provides the catalyst for changing the live auction process 
by ensuring an environment in which all parties— ^whether in person or in a remote 

15 location--can participate as one audience without impact to the natural flow, speed and 
excitement of the live auction. Qntv -Advantageouslv,w ife the present invention ean 

allows remote bidders to compete without disadvantage or a minimized disadvantage— 

-against live floor bidders in an instantaneous bid environment while realizing the true 
emotion and enthusiasm of the traditional auction setting. The remote bidding system of 

20 the present invention wa s s p e cifically d e signe d operates to enhance the live auction 

process rather than to alter it. The control of the auction always can easily remains with 
the live auctioneer and the auction company. The auctioneer can effectively and 
efficiently take bids firom either the local audience or fi'om the remote audience (e.g., via 
the Internet or some other local or global network) . As in all traditional live auctions, the 

25 auctioneer can accept or reject any given bid fi-om the local or remote audience. The 
system in effect greatly enlarges the potential pool of bidders by eliminating time, 
geographic or travel constraints on behalf of the bidder and quickly increases the 
potential reach of the auction company from a regional business to potentially a 
nationwide or worldwide business. 
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Crucial to Goals of a successful seamless integration of a remote auction audience 
with the local or onsite audience ar e features of th e present invention tha t include: (a) 
allow ing the remote bidder to rapidly make a purchase decisio n, (bV - not ali e nat e 
alienating the bidders who took the time to actually come to the auction even t, and (c)- 
5 while-instilling the confidence of all parties (onsite, remote and the auction company) in 
the integrity of the process. The remote bidding system of the present invention 
accomplishes this through the following systems of the present invention. 

1) AudioA^ideo System - The actual emotion and enthusiasm of a traditional- 
style auction event is transferred to the remote bidder or participant through streaming 

10 audio and vid e o technolog y and further enhanced through real-time video technology . 
The audio is transmitted from the auction site to the remote participants in one (1) second 
ey4es swith minimum delay through the network and the video is transmitted in real-time 
at a frame rate that supports a 56K modem connection to the network. Competing 
streaming live audio and video technologies of today utilize a buffering method at the 

15 encoding and/or the receiving end to achieve an acceptable level of quality for audio and 
video. In a traditional-style auction environment (i.e., dealer-only automobile auctions), 
an item may be sold every 3©-7_to 30 seconds with 30-a pproximately 10 to 3 OS bids. 
Buffering at the encoding and/or the receiving end typically adds 7 or more seconds in 
delay to the audio and video that would place the remote participant at an extreme 

20 disadvantage. The present invention removes the buffering without sacrificing quality 
and with a resulting delay of onl y that can be as little as one (1) second or less. 

2) Bid/Clerk Systems -,A Bid System controls the instantaneous interactions 
between the remote bidders, a Clerk System, and a Marquee System. The Clerk System 
controls the sequencing of items to be sold through the auction and controls the auction 

25 bidding process, both live and remote, for each item to be sold. The Marquee System 

displays instantaneously auction bid information for each item being sold at auction. The 
Bid System can include one or more bidding engines, including but not limited to the 
following bidding engines: 

a. Cherokee Bid Engine - The Cherokee bid processing algorithm within the Bid 

30 System allows the auction to proceed at a very fast pace (in excess of 440 -120 items per 
hour with sometimes as many as 30 bids per item). This algorithm uses a fixed increment 
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predictive algorithm to present bid choices to both the auction c Clerk System as well as 
the remote bidders. The Cherokee model also assigns the default high-priority to the 
remote bidders, but allows the auctioneer and elari eClerk System to change for any 
specific bid. 

5 b. Iroquois Bid Engine - The alternative Iroquois bid processing algorithm within 

the Bid System allows the auction to proceed at a fast pace while adding flexibility in its 
fixed increment predictive algorithm to accommodate a range of fixed increments 
depending on the actual last high bid. The Iroquois model assigns the default high- 
priority to the onsite/local bidders, while allowing the auctioneer and eteje -Clerk System 

10 to change any specific bid. 

c. Apache Bid Engine - The alternative Apache bid processing algorithm within 
the Bid System addresses many of the auction segments that do not operate with a fixed 
increment policy. In this model, th e cl e rk simply follows the auctioneer's "asking price" 
chant is followed by selecting the newest asking price on the Clerk System and allows 

15 remote bidders to submit a bid for that price. Th e Apach e model allows for fl e xibility in 
choosing the default high priority bid to b e e ither th e onsit e /local bidd e r or th e r e mot e 
bidder. 

3) Marquee System - Another critical aspect of the present invention is the design 
of the Marquee that is -can be p hysically placed at the auction site. For implementations of 

20 the remote bidding system where the auction selects to include the Marquee System, tT he 
Marquee is used to: 

a. identify incoming remote bids to the auctioneer; 

b. identify incoming remote bids to the onsite/local audience to create_confidence 
that there is a remote bidder and the identity of the remote bidder; and 

25 c. Id e ntify identify to the onsite/local audience the item being sold as well as the 

current high bid amount accepted (the onsite/local audience starts to bid off the 
Marquee). 

4) Data Mining - The data mining bid log processing capability of the present 
invention is a unique function that provides auction companies with the ability to quickly 

30 analyze the auction event's activity to assess national and international market value of 
the sale items, the participation of any or all remote bidders or the incremental value-add 
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brought by the remote auction capability. When the data mining bid log is evaluated in 
conjunction with the pre-sale catalog and the condition report of the item, an 
instantan e ous expeditious assessment can be made of how the features and the 
characteristics (e.g. damage to an automobile) of the sale item may impact the re- 
5 marketability of the item^- 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a schematic of the primary elements of the remote bidding supplement 
an exemplary environment suitable for an embodiment of the present invention. 

Figure 2 is a schematic of the dataflow within the remote bidding supplement of 
exemplary environment illustrated in Figure 1. 

Figure 3 is a schematic of the dataflow within th e exemplary environment 
between the AudioA^ideo Capture System 102 and the Bid System 120 of the present 
invention. 

Figure 4 is a schematic of the AudioA^ideo Capture System 102 of the present 
invention. 

Figure 5 is a schematic of the AudioA^ideo System 100 of the present invention. 
Figure 6 is an illustration of a Marquee System 140 D isplay display from the 
Cherokee Bid Engine of the present invention. 

Figure 6A is a block diagram illustrating the interface between the Marquee 
System dPisplay dDevice 108, the Mai'quee System 140 and the Bid System 120 for the 
transfer of display information. 

Figures 7 A and 7B areis-a flow diagrams illustrating details of tlie process flow 
for the Marquee System 140 in interfacing with the Bid System 120. 

Figure 6 A is a sch e matic of the dataflow for die Marque e Syst e m of th e pr e sent 
25 invention. 

Figur e 7 is a sch e matic of the Marque e Syst e m proc ess flow of the pre se nt 
inv e ntion. 

Figur e s 7A/7B illusti'at e initial Marquee System logon displays, Figur e 7A b e ing 
g e n e rat e d by th e Bid Syst e m of tli e present invention, and 7B b e ing th e display of 7 A 
30 after "us e r nam e " and "password" hav e be e n e nter e d. 
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Figure 7C illustrat o s a Marque e System display with a first DISMISS messag e . 
Figure 7D illustrates a Marquee System display with a second DISMISS message. 
Figure 7E illu s trates a Marqu ee Syst e m display after logon is complete. 
Figure 8 A illustrates an example of a display for a Biddinger Device 1 10 where 
5 the Cherokee bid engine has been implemented. 

Figure 8B is a block diagram illustrating the details of the interface between die 
Bidder Device 110 and the Bid System 120. 

Figures 9A and 9B k-aare flow diagrams illustrating the details of operation for 
the Bidder Device 110. 

8 A illustrates a Bidders Display from the Cheroke e Bid Engin e of the pres e nt 
invention. 

Figure 8B is a schematic of th e dataflow for tli e Bidder System/D e vice of the 
pr e s e nt inv e ntion. 

Figure 9 is a sch e matic of th e Bidd e r System process flow of th e pr e s e nt 
inv e ntion. 

Figur e 9 A illustrat e s an e xemplary Bidd e r Displav r 
Figiu-e 9A illustrates a Bidder Display after a URL connection i s made. 
Figure 9B illustrates a Bidder Display with "user name" and ''password" entered. 
Figure 9C illustrates a Bidder Display with a DISMISS message box. 
Figur e 9D illustrates a Bidder Display after the login sequenc e is completed. 
Figure lOA— illustrates an example of a Clerk System 130 display from the 
Cherokee Bid Engine. 

Figure 1 OB is a block diagram illustrating the interface between the Clerk System 
130 and the Bid System 120. 

Figures IOC and lOD io-are flow diagrams illustrating the details of operation for 
the Clerk System 130. 

Figure lOA illustrates a Clerk Display 

Figure lOB is a sch e matic of the dataflow for th e Clerk Sy s tem of tlie pres e nt 
inv e ntion. 

Figure IOC is a schematic of the Clerk System process flow of th e pres e nt 
inv e ntion. 
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Figur e 1 1 A/B illustrat e s th e initial Cl e rk Syst e m login display s . 

Figur e 1 IC illustrat e s the Cl e rk Syst e m Display with a first DISMISS m e ssag e 

Figure 1 ID illustrates a Clerk System Display with a second DISMISS m e ssag e 

5 hox. 

Figur e 1 IE illustrates a Cl e rk Syst e m Display aft e r th e login proc e ss is complete. 
Figure 12 is a schematic of the Bidding Process activation for an item to be sold at 
auction. 

Figures 13A/13B/13C illustrate the Marquee System 140, Clerk System 130 and 
1 0 Bidde r Device 110 D isplays displays after entry of Next Lot = l. a starting bid. 
Figure 14 is a schematic of the entry of a starting bid value. 
Figures 1 3D/1 3E/1 3F illustrate the Marquee System 140, Cler k System 130 and 
Bidder Device 110 Displays displays after entry of a starting bid from an onsite bidder . 
Figure 15 is a schematic of the process for entry of a floor bid. 
15 Figure 16 is a schematic of the process for entry of a remote bid. 

Figures 13G/13H illustrate the examples of the Marquee System 140 and Clerk 
System 130 Ddisplays when there is a pending remote bid. 

Figure 15 is a schematic of th e proc e ss for e ntry of a floor bid. 
Figure 16 is a schematic of th e proc e ss for e ntry of a r e mot e bid. 
20 Figures 13G/13H illustrate th e e xamples of th e Marqu ee and Cl e rk Di s plays wh e n 

th e r e is a pending r e mot e bid. 

Figure 17 is a schematic of the process for acceptance of a remote bid. 
Figure 131 illustrates an example of a Bidder Device 110 displayS ereen when 
there is an accepted remote bid. 
25 Figure 1 8 is a schematic of the process to override a remote bid. 

Figure 19 is a schematic of the process for a sold bid. 
Figures 13J/13K illustrate the Bidde r Device 110 and Clerk System 130 
©displays s cre e n s after SOLD is selected . 

Figure 20 is a schematic of the process for a remote user to request purchase 
30 information from the Cherokee Bid Engine. 

Figure 21 is a schematic of the process for th e cl e rk to deletinge a bid. 
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Figure 22 is a schematic of the process for the eteri eauctioneer to send a message. 

Figure 22A illustrates an example of a Message Screen. 

Figures 23A/23B illustrates examples of Bidder Device 110 displa v Scre e ns and 
Figure 23C is a Clerk System 130 displayS ereffl from the Mohawk Bid Engine of the 
5 present invention. 

Figures 24A/24B illustrate examples of a Bidde r Device 110 displa y - Scr e en and a 
Clerk System 130 displayS ereen from the Iroquois Bid Engine of the present invention. 

Figures 25A/25B/25C illustrate examples of Cler k System 130, Marquee System 
140, and Bidde r Device 110 dDisplays from the Apache Bid Engine of the present 
10 invention. 

Figure 26 illustrates an example of a Clerk Scr e en System 130 display from the 
Apache Bid Engine. 

Figure 27 illustrates an example of an updated Bidder Device 110 displayS creen 
from the Apache Bid Engine. 
15 Figure 28 is a schematic of the AudioA^ideo SubsS ystem of the present invention. 

Figure 29 is a schematic of the process flow of the AudioA^ideo SubsS ystem of 
the present invention. 

DETAILED DESCRIPTION S OF THE PREFERRED EMBODIMENTS 

Tb eTuming now to the figures, various embodiments and features of the present 
20 invention will be described. -One of the uniquenesses of the remote bidding supplement 
of the present invention is its ability to perform the remote bidder interactions in an 
instantaneous or near real-time environment independent of the distance between the 
remote bidder and the live auction. It should be understood that the terms instantaneous 
and near real-time are viewed from the user's perspective. Depending on the actual 
25 technology employed to implement the present invention, tlie speed and quality of the 
system can vary but, in any of the embodiments of the present invention, the goal is to 
provide interaction in a manner that appears to be instant from the user's perspective. 

Figure 1 is a schematic of an exemplary environment suitable for an embodiment 
of the present invention.T he - In the illustrated embodiment of the remote bidding 
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supplement of the present invention ^ r e quir e s sp e cific hardwar e and softwar e products_ 4e 
perform thes e functions the system includes : 

Three systems, each of which is preferably co-located, to perform the control 
functions of the auction: 

An AA^ System 100 to receive the audio/video stream firom 
the AA^ Capture System 102 at the auction and retransmit this 
stream instantaneously to each of the ^Bidder dPevices 1 10 of the 
remote bidders attending participating in the auction. This is part 
of the System Software. 

A Bid System 120 to control the interaction betwe e n 
among the bBidding dPevices 110 of the remote bidders, a_Clerk 
Syste m 130. and a Marquee Syste m 140 . This is part of the 
Syst e m Softwar e . 

A Catalog System 150 to maintain the pre-sales data on 
items to be sold (this ftmction may alternatively b e performed by 
either the AA^ System 100 or the Bid System 120 referenced 
above). In the normal auction configuration^ the pre-sales catalog 
information is kept on the Catalog System 150 . 

20 A Marquee System 140 to display current bid informatio n onto a Marquee System 

Ddisplay Ddevice 108 , from either floor or remote bidders, to the 

gallery/auctioneer/ringmen at the live auction. 

A Clerk Syst e m Systeml30 that controls the sequencing of items through the 

auction and controls the auction bidding process for each item to be sold. 
25 An AA^ Capture System 102 to provide the audio/video stream from the cam e ra 

Video Source 104 and Audio Source sound syst e m 106 at the auction to the AA^ System 

1 00 controlling the transmission of the stream to the bBidder dPevices 1 10 of the r emote 

bidders. Specific audio and vid e o captiu-e cards ar e r e quired for this fimotion. This is part 

of th e System Softwar e . 
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The remote bidding supplement of the present invention can p erforms the 
audio/video streaming and the remote bidder/clerk interaction as two independent 
flinctionsf. 

The AA^ Capture System 102 utilizin g , which may consist of specific- fee 
5 r e quir e d hardware cards installed in a computer system^ encapsulates the audio/video 
stream. The AA^ Capture System 102 interfaces to a Video Source 104 and an Audio 
Source 106. T his data is transmitted to a sp e cifio the AA^ System 100 where it is re- 
encapsulated and broadcast to each of the r e mot e bidd e rs bB idderiag dPevices 1210 
logged onto the system . This function ts- can be p erformed independent of the Marquee 

10 System 140, / Clerk System 130 and / Bid System 120s . In one embodiment. tT he auction 
bidding process k -can be controlled by the Bid System 120 and the Clerk System 130 . 
Data for each item to be sold is extracted from the system maintaining the pre-sales 
information prior to the auction start, a subs e t is cr e at e d transferred to en-the Bid System 
120, and is-broadcast to all remote bidd e r Bidder dPevices 1 10s and the Marquee System 

15 140 as eaeh -the items isare auctioned. A starting bid is established on the Clerk System 
130 and then bids are accepted from floor or remote bidders. Status is transmitted to the 
Marquee System 140 and aH -the b idd ^Bidder dPevice s 110 logged onto the auction , 
and logs are maintained identifying aHhactivity perform e d by th e clerk including status of 
each bid made by a remote bidder. 

20 A "-bid engine" algorithm on th e Bid System 12 0-is involved in control ings the 

remote bidding process. -There are four main bid engines that can be utilized. The 
primary functions of these engines are id e ntical similar; however,T ^ differences are -exist 
in the areas of automatic versus el^4t-controlled acceptance of a remote bid;^ bid 
increments used by the Cler k System 130 and Bidder Syst e m Pevice ISlO s;? ability to 

25 enter starting bids from e nt e r ed-by a bBidder dPevice 110 from a remote bidder^j and 
display formats. These engines are identified as: 
CHEROKEE 
IROQUOIS 
MOHAWK 

30 APACHE 
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Although specific details for each of these bidding engines are provided, these 
details are for illustrative purposes only and the present invention is not limited to the use 
of any one or multiple of these engines. Rather, other bidding engines can also be 
employed in various embodiments of the present invention. 
5 Th e syst e m configuration (Figur e 1) id e ntifi e s th e primary r e lationships betw ee n 

die e l e ments of th e r e mot e bidding s uppl e m e nt of th e pr ese nt inv e ntion. Th e thr ee 
primary systems work tog e th e r to support th e r e mot e bidding suppl e m e nt of the pr e s e nt 
inv e ntion. In a practical embodirrient of the present invention, the Each r e mot e bidding 
s uppl e m e nt of die pres e nt invention requires an AA^ System 100, the Clerk Syste m 130, 

10 and the Marquee System 14Q# tat are assigned to an "area" within the Bid System 120 
called an environment. Bidders logging onto entering into an auction through a bBidder 
dPevice 1010 are assigned to that same environment. 

Figure 2 is a schematic of the dataflow within the exemplary environment 
illustrated in Figure 1 . 

15 Th e data flow associated with th e syst e m of Figure 1 is shown in Figur e 2. 

Aspects of the present invention can be implemented using a variety of hardware 
platforms, software languages and programming environments. Those skilled in the art 
will readily observe that implementing the present invention in various environments will 
naturally require the use of various teclmologies. However, the present invention is not 

20 limited to any particular division of hardware/software fimctionalitv, hardware 

components, software languages, or programming techniques. Thus, references within 
this description identifying design particulars are provided only for illustrative purposes 
and should not be construed to limit the present invention. 

In addition, the exemplary environments identifying particular systems are 

25 provided for illustrative purposes. The various systems have been divided out into 

functional groupings. It should be understood that various fimctions could be perfomied 
on a single computer or on several computer systems operating in tandem . As an 
example, the Bid System 120, the Cl e rk Syst e m 130, th e Marqu ee Svst e m -440AA^ 
System 100 and the Catalog System 150 could simply be various software modules 

30 running on die same computer that includes a multi-tasking operating system and the 
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Clerk System 130. the Marquee System 140 and the AA^ Capture System 102 could also 
be operating on the same system at the auction site. 

The various functional systems of the present invention are described more fully 
below. However, it should be understood that any particular embodiment of the present 
5 invention may not necessarily include each and every functional system described. 

4-r4 SOFTWARE GENERIC STRUCTURE 

Th e following d e scriptions summarize th e d e v e lopm e nt structur e utiliz e d for the 
elements of the remot e bidding s uppl e ment software required for th e systems supporting 
the auction process. 

10 1.1.1 COMPONENT DESCR I PTION 

The cod e base for the Marquee, Cl e rk, and Bid Systems int e rface is mostly 
shar e d. Conti'ols hav e be e n mad e for e ach mam a s pect of the us e r int e rfac e (buttons, 
lab e ls, text box e s, e tc). Th e s e controls d e viate from th e standard JAVA AWT controls 
b e cause their look and functionality n e ed e d to be integrated with the r e st of th e AMS 

15 softwar e pres e ntation. The controls appearance on th e scr ee n is highly configurabl e in th e 
html pages that load the applet. If on e looks at the html (ringman admin.htm, ringman 
bidder.html and ringman quack.html)more detail will b e self evident. Classes wer e 
implemented per needed feature. The classes listen for events on the controls and re s pond 
appropriately by sending information to the network modul e , changing the state of other 

20 class e s, or changing th e stat e of oth e r controls. 

1.1.2 DATABASE 

Th e database i s currently implem e nt e d in POSTGRES.SQL. Tabl e s and ar e used 
for logging the bidder ev e nt s (proposed, acc e pted, rejected bids), tracking the sal e 
inventory (it e m d e scriptions, e tc), and tracldng u se r account s (usemame, password, e tc). 
25 For d e tails s e e th e POSTGRES initialization scripts (files e nding in .psql which initialize 
tli e database for th e Bid Sy s t e m). 
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1.1.3 BID SYSTEM/NETWORK 

Current n e tworking is impl e mented in UDP, original versions w e r e implement e d 
in TCP, which was found to b e too lat e nt (3 s e cond lat e nci e s in oas e s of c e rtain pack e t 
transmission failure) in testing to date. Th e curr e nt UDP syst e m re implem e nts most 
5 TCP to g e t around this. D e tails of th e impl e m e ntation con b e found in th e sourc e fil e 
"RUDP C" (which stands for r e liabl e UDP). Th e main probl e m with this solution to dat e 
has been the complexity r e quired in botli the Bid Devic e (chent) and Bid System. Mor e 
simple n e tworking code may replace th e RUDP impl e mentation in future upgrad e s. 
Parts of the Bid System use CGI (common gat e way interfac e ) programs for 
10 relaying information fro an SQL databas e to th e user. Th e Bid Syst e m structur e is to 
accept qu e ri e s, then look up th e appropriat e information from tho SQL databas e or its 
internal cach e , and then to d e termin e a r e spons e and s e nd it to a group of bidd e rs it has 
r e gist e r e d as b e ing int e r e st e d in that type of messag e . In this proc e ss it may alter the stat e 
of th e databas e . 

15 11.1 DEVELOPMENTl OPERATING E>JVIRONMENT 

The Bid System was develop e d and operates on Redhat Linux 2.0. The project is 
compiled in th e standard way with GNU CC for C portions and JAVAC for JAVA 
portions. Th e PSQL C library must b e linlced with th e final Bid Syst e m ex e cutabl e s. Th e 
Bid Syst e m should b e portable to oth e r Unix (POSIX) e nvironm e nts for d e v e lopm e nt, 
20 t e sting, and op e ration; this may r e quire modification, how e v e r. 

1.1.5 PLATFORM 

The Bid System curr e ntly runs on R e dhat Linux 2.0. It was writt e n to b e portable 
within PQSIX and BSD sock e ts. It will probably requir e modification b e for e it will run 
und e r oth e r environm e nts though. Such modification should b e straight forward and 
25 trivial, but to dat e no porting e fforts outside of Linux hav e b ee n made [no compatibility 
with non POSIX conformant syst e ms or syst e ms that do not implem e nt BSD sock e ts is 
eith e r e xpress e d or impli e d]. Th e Bid Syst e m uses up resourc e s proportional to th e 
amount of us e rs and size of the database it is serving. 

The Bidder D e vic e (client) software should b e portabl e to any machme that can 
30 run a JVM, However, it has only b e en t es ted to dat e und e r Windows/Netscape on 
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P e ntium Iiy4Q0mhz/192MB RAM and better machin e s. Limited te s ting on machin e s 
l e sser than this has revealed perfomiance d e ficits possibly in the JVM implem e ntation or 
som e aspect of th e design. Testing on oth e r JVMS has indicat e d JVM portability issu e s 
which look to be resolvable but will require modification to tlie struotiu' e of the client 
5 appl e t. 

1.1.6 L.WGUAGES 

The ringman server is implem e nted in C. Th e code was written to conform to (or 
at least b e portabl e to any implementation of) th e POSIX standard, e xcept for n e tworking 
section s which confomi with BSD sock e ts. The cod e was Miitten and tested in the Redhat 

10 Linux 2.0 environment with th e GNU C Compil e r 2.7.2 and has not been t e sted to dat e in 
any oth e r e nvironm e nts. Compatibility with oth e r e nviroimi e nts including, but not 
limit e d, to pr e vious and futur e version s of Linux, Windows, or any comm e rcial UNIX 
syst e m is n e ith e r expr e ss e d nor impli e d. UNIWC was chos e n because it is th e standard 
e nvironment for internet applications. 

15 The Onlin e Ringman cli e nt is implem e nted in Java. Java w^as chosen because it is 

currently the only widly used int e rnet WORA (write once run an3 f wh e r e ) packag e . 
Current versions of th e Ringman System have only been tested under the JVM distributed 
with Netscape Navigator. 

Futur e plans includ e moving the client application to Windows/C, which limits 

20 th e us e r bas e to window users but within that us e r bas e should p e rform fast e r and mor e 
r e liably and r e mov e d e p e nd e nc e on JVM impl e m e ntations. 

Portions of cod e that access th e SQL databas e w e r e writt e n with th e C v e rsion of 
th e postgres SQL library. CGI programs run und e r th e Apach e w e b s e rver. CGI was 
chosen becaus e it was th e simplest way to g e t information to a cli e nt. Since the program 

25 is written in Java, it was considered lilc e ly that tlie user would hav e acc e ss to a web 
browser with CGI capabihti e s: utilizing th e se capabiUtios was an e a s i e r, s impl e r, more 
e xt e ndabl e interfac e than adding portions to th e Java codo bas e ad hoc. 

AUDIOA^IDEO STREAMl^JG 

T a b le 1 
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MINIMUM A/V CAPTURE SYSTEM CONFIGURATION 

IBM Compatible Pentium HH 50 MHz 
128 MB SDR.\M PCI 00 (256 MB pr e ferred) 
CD ROM 
5 6A GB Hard disk drive 

1 . 44 MB Floppy driv e 
3COM 905 BTXNM 10/100 N16 
Standard keyboard and mouse 
VGA Display controll e r (1 02A x 768) 
10 Osprey 100 Video captur e cai'd 

Sound Blaster PCI 128 sound card 
15" Monitor 

Unint e rruptibl e Pow e r Sourc e Conv e rt e r 
Custom configur e d Red Hat LINUX 6.x Operating Syst e m 
15 AMS streamer control software 

Video Signal 
Audio Signal 

LAN connection to a high bandwidth connection to AN Syst e m 
The AA^ Captur e Syst e m is us e d to (a) convert th e signal fi-om the vid e o sourc e to 
20 a digital str e am, which is th e n transmitt e d to th e AN System on a continuous basis, and 
(b) conv e rt th e signal from th e sound sourc e to a digital str e am, which is th e n transmitt e d 
to tli e A/V Syst e m on a continuous basis. 

Th e .unit requir es a specific video capture card and a specific audio capture card 
in the A/V Captur e syst e m to p e rform the se two fiinctions. Th e ba s e operating syst e m 
25 utiliz e d by tlii s unit i s LINUX. 

3tI-S0FTWARE DESCRIPTION 

The software description for the AudioNid e o Audio/Video Streame r 102 is 
coritained in the 

Audio/Video SubsSystem Overview, infra. 
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3 DISPLAY UPDATE PROCESS GENERAL CONFIGURATION 
In the preferred embodiment, ff he Marquee System 140 . the Clerk System 130, 
and the Bid der Device Syst e m 12 0110s displays utilize a basic w e bsit e n etwork 
technology as the basis for displaying information specific to their fiinctions. Each 
5 system connects to a unique URL -network address as part of the login process for the 
system. Once the login process is complete, the system is linked to that w e bsit e network 
address. At that point, a base display is active and, Ln some embodiments, can be 
generated at specific GRT-coordinates on the sefeeftdisplay . The base display contains the 
background fi'ame with dynamic display areas blank. ftts -Advantageously. this js-deee 
10 te-reduces the size of the data packets required when an operator/system action is taken 
during the normal system operation. From this point forward, small data packets are sent 
to specific cursor addresses on the appropriate display. For example, when a floor bid is 
entered on the Clerk System 130; 

The Marquee System 140 display is updated with the specific bid amount and 
15 bidder #; 

The Clerk s y s tem System 130 is updated with new bid increments plus a log 
message : and 

The Bid der Device Syst e m 12 01 10 is updated with new bid buttons plus last bid 

value^ 

20 The second factor that is related to reducing the update time required for display 

changes is the ability to "broadcast" the same data to all systems connected to a particular 
UR Lnetwork address , primarily the bidde ^Bidder d e vic e s D evices 110 . Each system 
performing a particular fimction receives the same data at the same time firom the Bid 
Server 1 20 p erspective. The only delay in receipt of the information by -from the Bid 

25 System 120 is the inherent delay in the distance and method of the transmission over their 
respective communication links. 

Throughout the bid processing, movement of the scre e n cursor "selectable 
bar/button/etc." causes the selected item to either change color (e.g., yellow to red) or 
change from its idle color to no color fai.e.7, the frame color). 

30 The displays generated by the system can be changed either at compile time or 

within the HTML code used to output the static portions of the display. For example, 

' 17 
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NEXT ITEM can be replaced with NEXT VEHICLE for a Clerk System 130 display 
associated with an automotive auction; REMOTE BID could be replaced with 
INTERNET for a specific internet auction; the $ in activity log messages and on bid 
buttons can be changed to £ for an auction in the United Kingdom. Thus, the use of URfc 
5 based scr ee ns static portions on dynamic displays advantageously allows for greater 
flexibility in the bidding system. 

THE BID SYSTEM 120 

The Bid System 120 communicates with the Bidder Devices 110 over a 
communications network. To provide the instantaneous look and feel of operation, this 

10 network must be able to deUver information in a timely fashion. In a preferred 

embodiment of the present invention, the networking is implemented in UDP or RUDP 
(reliable UDP) altliough other technologies could also be utilized. For instance, a TCP 
network could be implemented; however, the UDP network is significantly more efficient 
in tliat the latencies in data deUvery are improved over TCP. Other networking 

15 techniques could also be employed and as technology advances, new techniques maybe 
preferred. 

In a preferred embodiment of the present invention, Parts-ef-the Bid System 120 
may-uses CGI (common gateway interface) programs for relaying information fi-om an 
SOL database to the user. The Bid System 120 structure is to accept queries, then-look 
20 up the appropriate information from the SOL database or its internal cache, and tben-te 
determine a response and send it to a group of bidders it has registered as being interested 
in that type of message. In this process, it may alter the state of the database. 

BIDDER DEVICE 110 

The Bidder Device 1 10 is used by a remote bidder to view the events at the Uve 
25 auction via the audio/video stream transmitted to each Bidder Device 110 from tlie AA^ 
System 100 and to interact with the auction through the Bid System 120, Clerk System 
130 and Marquee System 140. The bidder sefe^isplay of the Bidder Device 110 
dis pkvspresents a sequential history of the bids as eentreHeddefined by tlie Clerk System 
130. During the bidding for each item, the Bidder Device 1 10 allows the user to enter a 
30 bid for that item which is transmitted to the Bid System 120 controlling the auction. 
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Recognition of the bid and whether or not it is aeeepte d by th e svGt e m/cleF k-to be 
transmitted to the Clerk System 130 and Marquee System 140 is fetHmedcommunicated 
to the bidderBidder Device 110 and the Bid System 120 is then ready to aeeeptprocess 
another bid from that remote user. The acceptance of the bid and the display returned to 
5 the user can be conti'oUed by either the Bid System 120 or the Clerk System 130. The 
Marquee System 140 is independent of these actions and only receives "website updates" 
bas e d on their actions from the Bid System 120 based upon actions by the Clerk System 
130 and the Bidder Devices 110. 

In a preferred embodiment of the present invention. Tthe display used by the 

10 Bidder Device 1 10 tsmay be reset at three basic points in the process: 

1. The base display is generated and made available to all bidders as each 
bidder logs onto the required URLnetwork address. At this point the Bidder Device 110 
bidd^Klisplay may contains the audio/video stieam from the AA^ System 100 plus the 
base frame for the bid buttons. 

15 2. When the clerk enters NEXT ITEM, the display is updated to contain the 

information for the item in a pre-set area of the display. This data area is not updated until 
the NEXT ITEM is selected for the bid process. If the bidder legs-enteenters into the 
system in the middle of the bidding for a specific item, this area wiUmay not contain data 
until the NEXT ITEM is selected. 

20 3. The base frame (containing bid buttons and the activity log) ismav be 

updated each time an action is taken by the Clerk System 130. the remote bidder, or any 
other bidder during the bidding sequence for a particular item. 

The bidder display alsemav also contains one or more twe "RELOAD" links on 
the display-at- all tim e s . These links allow the individual bidder to reload a particular area 

25 of the displavT. 

In a preferred embodiment of the present invention, a Bidder Device 110 
reconnects to the A/V System 100 RELOAD und e r th e str e am data r e cormects to t he 
websit e URL t hat is broadcasting the audio/video stream when RELOAD near the video 
portion of the Bidder Device 110 display is selected.r-afid 

30 In a preferred embodiment of the present invention, a Bidder Device 110 

disconnects from the Bid System 120 and returns to the logon display when RELOAD 
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tmdemear the biddin g portion of the Bidder Device 110 display is selected.femte— 
dis conn e cts th e bidd e r fronn th e syst e m and returns to th e logon display for a bidder. 

Figure 8A illustrates an example of a display for a Bidding Device 110 where the 
Cherokee bid engine has been implemented. Figure 8B is a block diagram illustrating the 
5 details of the interface between the Bidder Device 110 and the Bid System 120. Figure 9 
is a flow diagram illustrating the details of operation for the Bidder Device 110. 

Figur e 9A illustrates an e x e mplary Bidd e r Display. 

4 BID SYSTEM AUCTION PREPARATIO N CATALOG SYSTEM 150 

Prior to the start of each auction, it is -may be necessary to upload catalog data and 
10 user data into the Bid System 1 20 specific to the scheduled auction. A subset of the 
catalog data is -may be utilized to generate the data that is displayed on the low e r l e ft 
portion of the b Bidder Device 110 display during the auction. The user file -data is used to 
identify the access each "bidder" has to the bid process (spectator, bidder with credit 
limit, eler kClerk System, Mmarquee System) . 

15 44 CATALOG PROCESSING 

The pre-sales catalog data is preferably m aintained as a separate data set for each 
auction. The maintenance of this data is not part of the process of the present invention. 
However, specific action must be taken prior to th e sale to execut e a script that r e trieves 
the data file from th e Bid System or the Catalog System and creates a"ruigman s ub - set" 
20 on th e Bid System (./updat e _db.sh). This subs e t is th e n us e d by tlio bid e ngin e to display 
th e low e r l e ft data for e ach it e m during th e bidding proc e ss. Depending on the format 
tha^the data is stored in, various pre-processing functions may be required prior to 
delivering the catalog data to the Bid System 120. For instance, in one embodiment, 
pointers may need to be set to the beginning of a bidders log and bid log file. In addition, 
25 it may be necessary to set tlie bid engine to 

Once th e data is creat e d it is n e c ess ary to e x e cute thre e s cript s on th e Bid System 
for this environm e nt: 

re se tbidtog s — sets tlie bidders log and bid log fil e pointers to thebeginning of fil e 

resctnohup — syst e m command for LINUX 
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rc s tartservcr s e ts the bid engin e to start at the first item in the database (a 
sequence number within the database can be used to estabhshes the order in which items 
are processed by the bid engine). 

4.3 UPDATE DB.SH SCRIPT PROCESS 

5 The updat e db.sh script cr e at e s th e hi one embodiment, a process may run that 

extracts an r ingman inventory subset firom the catalog data to be stored on or accessible 
to en-the Bid Syste m 120 . The ringman inventory subset contains the "lower l e ft" data for 
the bidders scree n Bidder Device 110 display and the-data for the Marquee System 140 
related to each item to be auctioned. Th e resulting table structure is in run nimiber order. 

10 The-seript is process extracts the r e quired inventory data from the inventory file 

provided to the Catalog System 150 and the r e quir e d condition report data from the 
damage file- data p rovided to the Catalog System 150 . The extracted inventory data and 
damage data afe -may be subsets of the total data provided for each item. The data 
extracted is dependent on the format defined by the auction, and subsequ e ntly must b e 

15 "specifically coded" for that auction. 

4:3 RESET BID LOGS SCRIPT PROCESS 

The res e tbidlags script res e ts the bidd e rs log and bid log pointers to b e ginning of 
file and clears data curr e ntly in th e file. This ensur e s a null fil e for the start of e ach 
auction. Of the script is not e x e cuted (op e rator controll e d), prior data is not cl e ared and is 
20 still part of th e curr e nt fil e . 

4.4 RESTARTSERVER SCRIPT PROCESS 

The r es tart se rver s cript resets th e intemal point e rs for tlie auction s e l e cted (via 
logon/posswsrd) to tli e start of the ringman subs e t such that the syst e m automatically 
starts at run numb e r 1 when th e Clerk Syst e m is activated. 

25 4 .5 USER FILE UPLOAD 

Th e Catalog System 1 50 may also contain a us e r fil er- The user file contains 
includes access information for each user scheduled to connect to the Bid System 120 
during an individual auction. Table 2 identifies an exemplary t he-format ef^for the user 
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file maintained s e parate from the bid server as a TAB d e limited file . The data fields in 
the user file af ecan include : 

Fieldl = user ED, this is the "logon" user name 

Field2 = password 
5 Fields = user type; 1 = bidder, 2 = clerk, 4 = marquee 

Field4 = credit limit for this auction 

Fields = field set to $0; during the auction, this field is updated on the Bid System 
120 to contain the total value of items purchased by each bidder^ 

The user file is fu'st up loaded to the for specific auction environments assigned to 
10 this auction without a file e xtension . The auction administrator then executes the The 
information in the user file can be formatted into updateusers s cript, which creates th e 
internal tables the bid engine utilizes 

during the live auction. Table 2 illustrates and example of such an internal table. 



Table 2 - User File Format 



5011748 


84711053 


1 


900000 


0 


user with $900,000 credit limit 


656 


1101265 


1 


999999999 


0 


user with unlimited credit limit 


52965 


3573179 


1 


20000 


0 




5033281 


182305 


1 


500000 


0 




5050186 


6810505 


1 


200000 


0 




5032832 


2382305 


1 


50000 


0 




5032025 


5202305 


1 


500000 


0 




5050658 


8560505 


1 


25000 


0 




5025609 


9065205 


1 


100000 


0 




5042804 


4082405 


1 


20000 


0 




5004057 


7504005 


1 


200000 


0 




5032640 


99983126 


1 


250000 


0 




5045095 


5905405 


1 


250000 


0 




5011587 


7851105 


1 


30000 


0 




5029894 


89583277 


1 


30000 


0 




10006 


6006 


1 


0 


0 


User with $0 credit limit =spectator 


10015 


150015 


1 


0 


0 




63046 


64036 


1 


999999999 


0 




5061648 


8461605 


1 


999999999 


0 




63056 


65036 


1 


999999999 


0 




5035425 


55245305 


1 


75000 


0 




5057863 


3687505 


1 


999999999 


0 




5058742 


2478505 


1 


999999999 


0 




5059001 


9500051 


1 


999999999 


0 
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Clerk 


Servnet 


2 


0 


0 


Clerk access 


Marquee 


Servnet 


4 


0 


0 


Marquee acess 


Userl 


lytdirdir 


1 


0 


0 




User2 


Abcdef 


1 


0 


0 





4:6 UPDATEUSERS SCRIPT PROCESS FLOW 

Tho updateusers script is e x e cut e d on th e Bid Syst e m to import data from aii 
e xt e rnal fil e into th e int e rnal tabl e s used to verify logon/password combinations and 
5 d e termine tlie type of acc e ss a us e r has. The input file must b e tab d e limited and contain 
th e data r e fer e nc e d in Tabl e 2. Th e tabl e construct e d in th e Bid Syst e m contain s th e sam e 
fi e lds with no added data. 

5 THE MARQUEE SYSTEM 140 

The Marquee System 140 is the visual link between the auctioneer/ringmen, the 
10 live gallery, and the remote bidder. The system Marquee System 140 can employs audio 
and/or visual prompts to the auctioneer to indicate that a bid has been made by the remote 
bidder. In some embodiments, T this system is -can be a display-only fimction that is 
controlled by the Bid System 120 b ased on inputs firom the biddeF -Bidder Device 110 
(entry of a bid)^ the Bid Syst e m 120 (automatic acceptanc e of a bid), or the Clerk System 
1 5 130 (operator acceptance of a bid . Next Lot etc.) . Th e control s e qu e nc e Is th e n res e t onc e 
the current bid has been proc e ssed. The Marqu e s Marquee System 140 is linked dir e ctly 
to an output port of interfaces to the Bid System 120 so g ueh-that messages (data packets) 
fi-om the Bid System 120 are automatically broadcast to the Marquee System 140 for 
output to the Marquee System D display Ddevice 108 . 
20 In the preferred embodiment, ¥ the Marquee System 140 operates to display: 

- indicat e s the current run # (item) being sold-and; 

- the current bidder ID (ED firom the user file for an remote bidder or "floor 
bidder" for any bidder at the auction); and 

the amount (whether the bidder is remote or at the auction). 

25 When a remote bid is received, the Marquee System 140 can flashes the display 

and /or provide an audible prompt- beeps to indicate a remote bid has been made plus as 
well as id e ntifies identify the remote bidder ID and the bid amount. Based on the type of 
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bid engine installed and the auctioneer's decision, this remote bid is either (a) accepted 
automatically or (b) r e quires through an ever^action by the Clerk System 130, rejected 
due to the auctioneer's decision to accept a bid from an onsite bidde rt o be acc e pt e d or 
continues to be in a pending state because the auctioneer has not accepted a bid from an 
5 onsite bidder that is a higher value than the pending remote bid. r 

Figure 6 illustrates an example of a Marquee Display for the Cherokee Bid 

Engine. 

Figure 6 A is a block diagram illustrating the interface between the Marquee 
System dPisplav Devicedeviee- 108, the Marquee System 140 and the Bid System 120 
10 for the transfer of display information, identifies th e configuration requirem e nts for th e 
Marquee System (see also Table 3) and 

Figures 7 A and 7B areis-a flow diagrams illustrating details of the depicts the 
process flow for the Marquee sSystem 140 in interfacing with the Bid System 120 . 

Upon starting the Marquee System 140, a boot process is performed 710. In some 
15 embodiments, the Marquee System 140 is accessed via a computer running a browser 
interface and entering a unique tJRLnetwork address for the Marquee System 140. Once 
the boot process is complete, the Bid System 120 requires a login procedure to be 
performed 720. Once the login process is completed, the Bid System 120 interacts with 
the Marquee System 140 to display various scre e ns items or images tethat indicate the 
20 status of the auction, entrance of bids, etc. 

Tab le 3 

MINIMUM MARQUEE SYSTEM CONFIGURATION 

IBM Compatible Pentium 200 MHz 
25 32 MB RAM 

CD ROM 

^.8GB Hard di s k drive 
1 . 44 MB Floppy driv e 
3COM 10/100 Eth e rnet NIC 
30 Standard k e yboard and mous e 

VGA Display controller (1021 x 768) 



24 



Attomey Docket Number 01 004. 1000 

Sound Blaster compatible sound card with spealc e rs^ 

(^Compaq sound card i s not compatibl e ) 

RGB (SVGA) to NTSC convortor (if display accepts NTSC) 
Unint e rruptible Power Source/Conv e t e r 
5 Windows 95,98, or NT operating syst e m 

Netscap e 4 .05 or later 
Display D e vice 

Figures 7A/7B illustrate initial Marqu e e Syst e m logon displays; th e first 
10 generated by tlie Bid System while th e second shows the display after "user name" and 
"password" have been entered. Figure 7C illustrat e s a Marquee System display with first 
DISMISS message; the operator chcks on DISMISS to eliminate messag e box. Figure 7D 
illustrates a Marquee System display with second DISMISS messag e ; the operator clicks 
on DISMISS to e liminate messag e box. Figure 7E illustrat e s a Marquee System display 
15 after login is compl e te, with no action taken by cl e rk at this point. 

€ BIDDER SYSTEM 

The Bid System is used by a remote bidder to view the events at the live auction 
via the audio/video stream transmitted to each logg e d on bidder. In addition, th e bidder 
scre e n displays a s e quential history of th e bids as controlled by th e Clerk Syst e m. During 

20 the bidding for e ach item, th e Bidder Device allows th e user to enter a bid for that it e m 
which is transmitted to the Bid Sy s tem controlling the auction. Recognition of the bid and 
wh e ther or not it is accept e d by the s ystem/clerk is returned to th e bidd e r and the Bid 
System is th e n ready to accept another bid from that r e mot e user. The acc e ptance of th e 
bid and th e display r e turn e d to th e us e r is controll e d by th e Bid Syst e m and th e Clerk 

25 Syst e m in diff e r e nt combinations bas e d on the install option s e l e ct e d by an auction. The 
Marque e Syst e m is ind e pendent of th e s e actions and only receiv e s "w e bsit e updat e s" 
bas e d on th e ir actions. Th e sp e cific int e ractions b e tw ee n tlie Clerk and Bid Syst e ms ar e 
d e fin e d in th e Bid Engin e Proc es s e s s e cti o n in frar 

Th e display us e d by th e bidd e r is r e s e t at thr ee basic points in th e proc e ss: 
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h Th e bas e display is g e nerated and mad e available to all bidd e rs as each 

logs onto the required URL. At this point, th e bidder display contains the audioAddeo 
stream from the A/V Syst e m plus th e bas e frame for the bid buttons. 

Or, Wh e n th o Clerk ent e rs NEXT ITEM, the display is updated to contain th e 

5 infoimation for th e it e m in a pre s e t ar e a of tli e display. This data area is not updat e d until 
th e n e xt item is s e l e ct e d for the bid proc e ss. If th e bidder logs onto the system in the 
middl e of th e bidding for a specific item, this ar e a will not contain data until th e NEXT 
ITEM is s e l e ct e d. 

3^ The base frame (containing bid buttons and the activity log) is updated 

10 e ach time an action is taken by th e Clerk System, this bidder, or any other bidd e r during 
th e bidding s e qu e nc e for a particular item. 

The bidd e r display also contain s tv^o "RELOAD" linlcs on th e display at all times. 
Th e s e linlcs allow th e individual bidd e r the abiUty to r e load a particular ar e a of th e 
di s play: 

15 RELOAD under th e str e am data r e conn e cts to th e website URL that is 

broadcasting the audio/vi e o stream. 

RELOAD under tlie bidding frame — disconnects the bidder from the system and 
returns to th e logon display for a bidder. 

Figure 8 A illustrate s an example of a Bidders Display from the Cherokee Bid 
20 Engine. Figure 8B identifi e s th e configuration required for the Bidder Device and Figur e 
9 d e fin e s th e base proc e ss flow for th e bidder fimction. 

Tab le 4 

MINIMUM BIDDER SYSTEM CO^JFIGURATION 

IBM Compatibl e — Pentium 133MHz . 
25 16 MB RAM (32 MB R.\M profon'od) 

Hard disk driv e 

1 . 44 MB Floppy driv e 

3COM 1 0/1 00 Ethemet NIC for high s peed LAN connections or 56Kbps 
30 mod e m with activ e phone lin e 
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Standard k e yboard and mouse 

Color di s play (800 x 600 2 4 bit color compatibl e ) 

Sound - Blaster compatibl e soimd card with spealc e rs'*' 

*Compaq s ound card is not compatibl e 

5 Windows 95, 98, or NT operating syst e m 

N e tscap e 4 .05 or later 

N e tscape plug in r e quir e d by AMS softwar e 

Figur e 9A illustrates Bidder Display aft e r a URL connection is made. Figur e 9B 
10 illustrates a Bidder Display with "user name" and "password" entered. Figure 9C 
illustrates a Bidder Display with a DISMISS m e ssag e box. Th e bidd e r clicks on 
DISMISS to d e lete m e ssage box and to g e nerate bas e Bidder Display shown in Figur e 
6D. Figur e 9D illustrates a Bidder Display aft e r the login s e qu e nc e is complet e d. 

7 The CLERK SYSTEM 130 

15 The Clerk System 130 is used to control represent the bid ding activities from both 

the floor and remote bidders in conjunction with the controlling Bid System 120 . Entries 
made via the Clerk System 130 result in display changes for all logged ow active bidders 
and the Marquee System J40. The action resulting from a particular entry is dependent on 
the "bid engine" being utilized by an individual auction. Thes e engines are: 
20 Cherokee 
Iroquois 
Mohawk 

Apach e (aslcing pric e model) 

Figure lOA illustrates an example of a Clerk System 130dS isplay from the 
25 Cherokee Bid Engine. Th e configuration required for tlie Clerk Syst e m is shown in 

Figure lOB is a block diagram illustrating the interface between the Clerk System 
130 and the Bid System 120. 

Figure IOC is a flow diagram illustrating the details of operation for the Clerk 
System 130. 

30 and m Tabl e 5, and the bas e process flow for the system is contamed in Figure 11. 

Tab l e 5 
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MI>nMUM CLERIC SYSTEM CO^fFIGURATIQN 

IBM Compatible Pentium 358MH2 
32 MB RAM 
CD ROM 
5 4 .0 GB Hard disk driv e 

1. 44 MB Floppy drive 
3COM 10/100 Ethomot NIC 
Standard k e yboard and mous e 
VGA Display controll e r ( 1021 x 768) 
10 Sound Blaster compatibl e sound card with sp e alcers'*' 

C^Compaq sound card is not compatibl e ) 

17 inch CRT display (0.27 mm dot pitch) 
Uninterruptible Power Source/Conv e rter 
Windows 95, 98, or NT op e rating syst e m 
15 N e tscap e 4 .05 or lat e r 

Figures 1 lA/1 IB illustrat e th e initial Cl e rk System logon displays. Figur e 1 1 IC 
illustrat e s th e first DISMISS message box; the operator clicks on DISMISS to delet e the 
message box. Figure UD illustrate s th e s econd DISMISS message box; the operator 
cUcks on DISMISS to delete message box. Figure 1 IE illustrates a Cl e rk System display 
20 after the login proc e ss is complete. 

8 ^BID ENGINE PROCESSES 

The bidding process involves the Clerk System 130, the Marquee System 140 , 
and all bidders logged ente -into the auction. The specific process utilized for an 
individual auction is based on the "Bid Engine" selected by the auction to control this 

25 process. The base operations of the Bid Engines i-s -are simila ri dentical in how the data 
packets are sent to the systems and the content of the data. Differences are primarily in 
the area of how remote bids are requested/accepte d (eith e r automatically or via a clerk 
e ntry), ; the bid value options on th e valu e to bid presented to the Bidder Devices 110 
(i.e., one bid value —that is the next higher sequential value versus five multiple bid value 

30 options);^ and the ability to -set policy^ thereby changing bid increments based on the 
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value of the last accepted bid (i.e., increment always by a fixed value versus incremen ting 
by $25 up to $3000, $50 up to $4000, and then by $100 increments). 

The data sent to the Marquee System 140 is basically the same for each of the Bid 
Engines. Logjging Log-in displays are performed in the same manner in all Bid Engines;^ 
5 the content of specific messages varies by bid -Bid ^ ngm eEngine . Display format 
differences are in the bidding feame -portion on the biddet ^Bidder devic e D evice 110 
display and the bas e clerk displa y of the Clerk System 130 . 

Each of the Bid Engine processes is defined in the following sections. Once the 
Marqu e e System 1 4 0 , th e Clerk System 130 , and Bidd e r Devices 110 ar ^ is active 
10 (logged on) and the base-displays broadcast, the process becomes event driven based on a 
eleri eClerk System 130 or Bbidde r Device 110 action, entry on th e ir r e sp e ctive syst e m s . 
The process flows identify the actions taken by the Bid System 120 in response to the 
initiation of these events . 

874 OPERATION OF THE CHEROKEE BID ENGINE 

1 5 The following processes for the Cherokee Bid Engine are detailed in the 

respective figures as defined throughout this section. in th e process flow charts below. 
Once the Marqu e e, Clerk System 130 , and Bidd e r D e vices hasve been initialized, the bid 
engine reacts to e ntrie s made by either th e c the actions of the C ler k System 130 or the 
biddef Bidder Device 110 . 
20 Initiation of first item or next item (Clerk System 130 function) 

Enter starting bid (Clerk System 130 funcrion) including +1/- $500 button use 
Enter floor bid (Clerk System 130 function) 

Enter/accept remote bid (Bidde r Device 110 /Clerk System 130 function) 
Sold Bid-bid (Clerk System 130 fimction) 
25 Request purchase info (Bidde r Device 110 function) 

Delete Bid-bid (Clerk System 130 function) 
Message (Clerk System 130 function) 
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8.1.1 ACTUATION OF THE BIDDING PROCESS FOR FIRST, NEXT, OR 
ANY ITEM 

Figure 12 illustrates the activation of the Bidding Process for an Rem item . Figures 
13A/i3B/l3C are examples of the Marque e System 140 display. Clerk System 130 
5 display , and Bidder Device 110 displays following the initiation of the first ftem -item in 
the sequence. The cl e rk establish e s th e The sequence of items is_based on the use of the 
NEXT ITEM bar 1305 on the displayv. 

The first item can be selected by entering 1 and then clicking on NEXT ITEM; or 
clicking on NEXT ITEM if no other prior activity has occurred since the system was 
10 activated (the system presets to item_l of the ringman inventory subset data created from 
the pre-sales catalo g in the updat e dbsh proc e ss ). 

The next item is normally selected by clicking on NEXT ITEM. The next 
sequential entry defined in the ringman inventory subset is selected. Any item can be 
taken out of sequence by entering the ringman inventory subset number and then clicking 
15 on NEXT ITEM. Successive NEXT ITEM entries are then based on the last item 
selected. 

In a preferred embodiment of the present invention, T the NEXT ITEM entry is 
the single-point tha ^when the "lower left" data is output to the bidd ^Bidder Device 110 
display and the fettr-display area{s) on the Marquee System 140 is/ are updated for the 
20 next item in the bidding process. These areas are usually n ot changed until NEXT ITEM 
is entered. 

The sequence of items is determined from the pr e sal e s catalo g inventorv 
information during the update_db.sh process . This process (defined in s e ction 4 .2) cr e ates 
a "ringman subs e t" on the Bid System prior to the start of the auction. This data s ub se t 

25 contains the run number, lower l e ft data ( s pecific fi e lds from tlie pr e sal es catalog data 
d e fined by th e auction) and the standmg bid if provided. During the NEXT ITEM 
process, th e Bid System extracts th e data from th e ringman subs e t, bas e d on th e run 
number, and s e nds the n e c e ssai'y data to pr e d e fined screen locations for th e Marqu ee , 
Cl e rk, and Bidd e r D e vic e s. 

30 Figures 13A/13B/13C illuotrato Marqu oo /Cl o rlc/Biddor Displays after tlio first 

item is s e lected. 
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SrirS-ENTER STARTING BID 

Figure 14 schematically illustrates the entry of a starting bid. The clerk initiates 
the bidding process for each item by entering a starting bid for that item. This typically 
can be accomplished by two methods: 
5 (1) Enter a user name plus a value (num e ric, no $ sign) in the two areas above the 

CHANGE BID bar. Then click on CHANGE BID. This will signal the initiate ion that the 
bidding has begun b y setting a starting value plus an entry in the activity log and setting 
the bid increment bars on both the eleri ^lerk System 130 display and the bBidder 
Device 110 displays. The bid increment bars are preset for $iQQ pre-defined increments 

1 0 for fes -the Cherokee b Bid eEngine. 

(2) Click on the +/- $500 bars (for auction events where $500 is not the preferred 
value, the +/- value can easily be changed) until the desired starting value appears on one 
of the bid increment bars on the right side of the Cler k System 130 Displav display . Then 
click on the starting value bar. The system then generates the Clerk System 130 display 

1 5 and Bidder Device llO Ddisplays as done for the CHANGE BID entry. 

From this point forward until the completion of bidding for a particular item 
(SOLD or NEXT ITEM), the CHANGE BID function can be utilized to enter a bid from 
a particular user or to jump the bid more than the amount shown on the last bid increment 
bar on the Clerk System 13QD display. If a user ID is not entered, the system defaults to 

20 "floor bidder." The CHANGE BID process can also be utilized to override a remote bid 
with an equivalent floor bid (the default setting for the Cherokee Bid Engine as cliclcing 
on th e bid valu e automatically assigns the bid to an remote user if athat remote user's 
pending b id is equal to the value identified by the selected bid increment ba r has b e en 
mad e at th e that pric e). 

25 The +/- $§SO- 500 b ars are only active fer-fe ebefore the first bid on any sp e cific 

item has been accepted . After the initial (starting) bid is entered, these bars are inactive 
until SOLD or NEXT ITEM is entered on the Clerk System 130D display. 

Figures 13D/13E/13F illustrates the Marqu ee /Clorlc/Bidd e r Displavs Marquee 
System display 140, Clerk System 130 display and Bidder Device 110 display aftmipon 

30 acceptance of a- the starting bid. 
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8.1.3 ENTER FLOOR BID 

Figure 15 schematically illustrates the entry of a floor bid. In a preferred 
embodiment of the present invention. To ent e r a floor bid, th e cl e ric follows one of two 
sequences have occurred on the Clerk System 130 : 
5 (1) Click on Tthe value of the floor bid on the increment bars if -has been selected 

and there is no bid from a remote bidder, (flashing Marqu ee Display). 

(2) Bfttei^Tthe value has been entered in the data entry area near space above 
CHANGE BID and then click on CHANGE BID is selected . 

In either case^ the Marque e System 140, Cler k System 130 and Bidder Device 110 
10 Displays displays are updated to reflect the accepted bid value and the increment bars ^ 
reset for the preparation for next bid to be entered. The CHANGE BID sequence is 
typically used if the value of the bid to be accepted exceeds the highest value on the bid 
increment bars or the clerk e nters a bid prior to a value being recognized by the 
auctioneer is transmitted from the Clerk System 130 to the Bid System 120 and the elerit 
1 5 accepted bid value must be reset the bid to a lower value. 

8.1.^ ENTER/ACCEPT/OVERRIDE REMOTE BID 

%ArAA ENTER REMOTE BID 

Figure 16 schematically illustrates the entry of a remote bid in a preferred 
embodiment of the present invention . To enter a bid from a remote bidder, the bidder 

20 ty pically selects etieks the large value button that shows the next incremental bid value. 
The system validates the credit limit by adding dollars spent to this bi d value . If the value 
exceeds the pre-defined credit limit, a FUND message box is displayed on the Bidder 
Device 110 Scr ee n display . The bidder then clicks on the DISMISS area of the message 
box and the system resets the display such that a new bid could be entered. This FUNDS 

25 message box is regenerated each time the bidder enters a bid that would exceed the 
allow e d tota l his/her credit limit . This message is also displayed if a spectator with a 
(credit limit equal to = $0) attempts to make a bid. If the bid is within thea credit limit as 
defined above, th e system s e ts th e Marquee to flash and b e ep signifying an open romoto 
bid has b e en e nter e d. Th e activity logs ar e also updat e d on th e cl e rk and bidd e r scroons to 

30 r e fl e ct this condition, the Bid System 120 updates the Clerk System 130 with the 

proposed remote bid and updates the activity log on the Clerk System 130 and Bidder 
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Device 1 10 displays. If a Marquee System 140 is included in the installed configuration, 
the Marquee System 140 will show a visual alert (i.e., flash) and may also sound an 
audible alert (i.e., beep) signifying a remote bid has been proposed. 

If two or more remote bidders enter the same bid value at the same time, the 
5 system takes the first bid received. Any-Oether remote bidders who have entered the 
same bid value have the display reset with the OUTBID message. 

Figures 13G/13H illustrate Marquee System 140 and Cler k System 130 displays 
when there is a P e nding p ending rR emote bBid. 

Sri.4T3 ACCEPT REMOTE BID 

10 Figure 17 schematically illustrates the acceptance of a remote bi d in a preferred 

embodiment of the present invention . To accept the remote bid, th e cl e rk clicks on the 
increment bar on the Clerk System 130 Display containing that value is selected (top bar 
on th e right) . An alternative method is to enter the remote user JD and the value and then 
click o n select CHANGE BID. For either sequence, the Marquee System 140, Clerk 

15 System 130, and Bidder Devices 110 are reset to identify the accepted bid. If a Marquee 
System 140 is included in the auction's configuration. This will stop the Marquee System 
Displa y 108 will stop flashing/beeping. 

Figure 131 is an illustration of an accepted remote bid on the Bidder Device 110 
display. Scr e en, 

20 87iT4r3 OVERRIDE REMOTE BID 

Figure 18 schematically illustrates the override of a remote bi d in a preferred 
embodiment of the present invention . If the same bid is received fi*om both the floor and 
the remote bidder, the cl e rk can acc e pt the remote bid can be accepted ( as defined above) 
or aee^t-the floor bid can be accepted ( by entering the value and clicking on CHANGE 
25 BIDir(the system defaults to "floor bidder" if no bidder ID is entered for the CHANGE 
BID function). The Bidder Device llOdS isplay contains an OUTBEED message if the 
floor bid was accepted. If a Marquee System 140 is included in the auctions' 
configuration. This will stop the Marquee System D ispla y Device 108 will stop 
flashing/beeping. 
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8.1.5 SOLD BID 

Figure 19 schematically illustrates the process for a sold bid in a preferred 
embodiment of the present invention . To sell an item to either a floor or remote bidder, 
tho clerk must first acc e pt the final bid must have been accepted as previously discussed 
5 in sections 8.1.3 or 8.L4 . The clerk th e n cUcks on th e SOLD butto n is then selected to 
complete the sale for that item. The activity log and the Marquee System Displa y Device 
108 (if the Marquee System 140 is included in the configuration) identify the value^ m4 
the remote bidder name or the indication of a / ^"floor bidder" — all specifically relating to 
the sold item, as the p e r s on buy e r of that item. 
10 If the item was sold to a remote bidder, the system updates the user tables as 

follows: 

The user fil e SPENT column for that user is updated to reflect the sum of any of 
his/her p rior sales to thi s user p lus this sale such that subsequent credit limit checks are 
based on the current dollars spent by this remote user. 
1 5 The table is updated to reflect the information for the item just purchased by the 

remote bidder (Usting of each item purchased, value, and time). This data is then 
available to the remote user at any time during the auction by clicking on PURCHASE 
INFO at th e top of th e bidd e r on the Bidder Device 110 displa y (section 8.1.6) . 

Figures 13J/K illustrate the BidderlClerk Bidder Device 110 /Clerk System 130 
20 Scr ee ns displays afte rwhen the item is SOLD. 

8.1.6 PURCHASE INFORMATION (REMOTE BIDDER) 

In a preferred embodiment of the present invention. Figure 20 schematically 
illustrates the remote bidder's process for requesting purchase information in the 
Cherokee Bid Engine. When a remote bidder clicks on the PURCHASE INFO button on 

25 the Bidder Device 1 10 Ddisplay, the system links that bidder only to a new websit e p age 
that contains the purchase history for that remote bidder for this the specific auction 
currently being attended . An example of a portential T he format of the w e b s ite p age is 
shown below. To retum to the Bidder Device 110 D display, the user clicks on BACK or 
the X in the upper right comer of the w e bsit e displav p age . 

30 username 656 
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password abcdefg 

purchase total 1 8400 

catalog number amount time 

15 6500 09:26 

5 27 11900 10:12 . 

8.1.7 D ELETE BID 

Figure 21 schematically illustrates the process for deleting bids in a preferred 
embodiment of the present invention . The clerk is abl e to "del e te" Aa bid is deleted b y 
clicking on DELETE BID on the Clerk System 130 dP isplav. The system deletes all data 
1 0 for that bid from the activity logs on the Clerk System 130 display and Bidder D evice 
110 d isplays, resets the Marquee System 140 to the last accepted bid data, and resets the 
bid increment bars on the Clerk System 130 display and Bidder D evice 110 d isplays 
based on the last accepted bid prior to the bid being deleted. 

8.1.8 MESSAGE FUNCTION 

15 The message function is used by the cl e rk to send a message to either a single 

remote bidder or to_broadcast to all remote bidders. The message format defines the type 
of message to be processed. Figure 22 A illustrates an example of a message screen. 
Figure 22B schematically illustrates the typical message process. 

8t3 OPERATION OF THE MOHAWK BED ENGINE 

20 The following processes for the Mohawk Bid Engine are detailed in the respective 

figures as defined throughout this sectio n d e tail e d in th e proc e ss flow charts list e d b e low . 
Once the Marque e Syst e m 1 4 0 , Clerk System 130 , and Bidd e r Devic e s have -has b een 
initialized, the Mohawk Bid Engine reacts to efttries -Clerk System 130 or Bidder Device 
110 actions mad e by e ither the Cl e rk or th e r e mot e bidd e r . For example, in one 
25 embodiment the following operations can be performed: 

Initiation of first item or next item (Clerk System 130 fimction)** 

Enter starting bid (Clerk System 130 function) including +/- $500 button use** 

Enter starting bid from Remote Bidder 

Enter floor bid (Clerk System 130 fimction)** 
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Enter/accept remote bid (B MBidder Device 110// Clerk System 130 function)** 

Sold Bid-bid (Clerk System 130 function)** 

Request purchase info (Bidde r Deyice 110 function)** 

Delete Bid-bid (Clerk System 130 function)** 
5 Message (Clerk System 130 function)** 

** these items function similarly to the s sam e as Cherokee Bid Engine 

The Mohawk Bid Engine is th e sam e as th e Ch e rok ee Bid Engin e described in th e 
pr e vious s e ction with add e d capabiUties for: 

Entering a starting bid from a remot e bidde r also mcludes 
1 0 Ffour additional multiple bid value buttons^ 

Figures 23 A/23B illustrate exemplary Bidder Device 110 displays Scre e ns and 
Figure 23C an exemplary Clerk System 130 display Sereen from the Mohawk Bid Engine. 

8.2. 1 MULTIPLE ADDITIONAL BE) BUTTONS ON BIDDER 
SGREB NDEVICE 1 10 DISPLAYS 
1 5 The Mohawk Bid Engine has five -multiple b id bars on the Bidder D evice 110 

displa y. In a configuration with five bid bars, the TV the-main bar is for the next higher 
$jrQO-increment (default) from the last accepted bid while the remaining four bars are for 
values $200/$300/$ 4 00/$500 two times, three times, four times and five times high e r than 
the default incremen t last acc e pt e d bid . The remote bidder clicks on the value desired to 
20 enter a bid in the same manner as previously described for the Cherokee Bid Engine. The 
Bid System 120 r ecognizes which bar has been selected and updates the Marquee System 
140, Clerk System 130 , and Bidder D evice 110 d isplays accordingly. Acceptance of the 
bid is handled much the same way as the Cherokee Bid Engine with the primary 
exceptions being as follows 

25 i) If two or more remote bidders submit bids of different values, the first 

bid received is submitted to the auctioneer. If the other remote bid(s) 
is/are of higher value then the previously received pending bid, it/they 
are queued for presentation to the auctioneer following the auctioneer's 
action on the previously received pending bid. 
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2} If a remote bidder submits a bid of value greater than the minimum 

increment and the auctioneer accepts a bid from an onsite bidder of 
lesser value, than the remote bid remains pending until the auctioneer 
accepts it, accepts another bid of higher value or sells the item. 
5 For this process, th e Bid System must output fiv e values to updat e th e Bidd e r 

D e vic e 1 10 d isplay inst e ad of a single valuo. 

8.2.2 ENTRY OF A STARTING BID FROM THE BIDDER 

SYSTEM D EVICE 110 

To enter a starting bid from the Bidder Device 110, the bidder enters a value 
1 0 numeric, no dollar sign) and clicks on STARTING BID. The Clerk System 130 then (a) 
accepts the starting bid by entering the value phi sand selecting CHANGE BE) or (b) 
overrides the remote starting bid by entering a different value 4= -plus selecting CHANGE 
BID. Once the bidding has been initiated for a specific item, the bidder^s starting value 
entry bar is -may be deactivated until NEXT ITEM is selected on the Clerk System 130 . 
15 The process is the same as that used to Ente renter , Aeeeptaccegt, or Ov e rrid e override a 
remote bid as previously defined for the Cherokee Bid Engine. 

8t3 OPERATION OF THE IROQUOIS BB»4 SBID EN GINE 

The following processes for the froquois Bid Engine , in a preferred embodiment 
of the present invention, are detailed in the respective figures as defined throughout this 
20 section are d e tail e d in th e proc e ss flow charts Ust e d below . Once the Marquee, Clerk^aad 
Bidd e r Systems -130 hasve been initialized, the bid engine reacts to the e ntri e s mad e by 
e ith e r th e cl e rk or th e remot e bidd e r Clerk System 130 or Bidder Device 110 actions . 

Initiation of first item or next item (Clerk System 130 fimction)** 

Enter starting bid (Clerk System 130 function) including +/- $500 button use** 
25 Set Policy (Clerk System 130 fiinction) 

Enter starting bid from Remote Bidder** 

Enter floor bid (Clerk System 130 fimction)** 

Enter/accept remote bid (Bi dBidder Device 110// Cler k System 130 fimction) 
Sold Bid (Clerk System 130 fimction)** 
30 Request purchase info (Bidde r Device 110 fimction)** 
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Delete Bid (Clerk System 130 function)** 
Message (Clerk System 130 fimction)** 

** these items functio n similarly s s ame as to the Cherokee or Mohawk Bid 
Engines. 

5 The Iroquois Bid Engine provides the following additional capabilities in addition 

to those of the Mohawk Bid Engine: 

A specific button (REMOTE BED) must be selected to accept a remote bid^i 
chcldng on selecting the bid value button accepts that same value from a floor bidde r; and 
SET POLICY— allows the auction to identify what bid increments are to be used 
10 based on the bid value (e.g., up to $2^000^ use $25 incrementsr^for the next $2^000^ use 
$50 incrementSrLabove that levels ¥r^use $100 increments). 

This affects the process used by the Bid System 120 to redisplay the eleri eClerk 
System 130 and Bidder Device 110 b idderbid bar values as each bid is accepted. 

Figures 24A/24B are examples of a Bidder D evice 110 -d isplay and a Clerk 
1 5 System 130D display from the Iroquois Bid Engine. 

8.3.1 ACCEPTANCE OF A REMOTE BID 

Acceptance of a remote bid is accomplished by clicking o n selecting the 
REMOTE BID bar at th e top of on the Clerk System 130D display. The resulting p rocess 
is the same as defined for the Cherokee Bid Engine for an accepted remote bid. If the 
20 Cl e rk clerk clicks on the value bar equivalent to the remote bid on the Clerk System 130 
display is selected , the bid is assigned to the "feetfloor". For this condition, the process is 
the same as the override process described for the Cherokee Bid Engine. 

8.3.2 SET POLICY FUNCTION 

The SET POLICY function is used to define the bid increments to be used on the 
25 bid increment bars on the Clerk System 130 and Bidder D evice 110 d isplays for each 
item to be auctioned. In a preferred embodiment of the present invention. T the Clerk 
System 130 caimot set starting bids or accept bids until the SET POLICY function has 
been completed. 

The clork oliokQ on tho SET POLICY bar on the Clerk System 130 display is 
30 selected at tho bottom l e ft of the Display. This to activates the set policy box on the Clerk 
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System dP isplay. Th e Cclerk th e n s ets Aas many increment definitions as necessary are 
established by entering values in the two lines initially displayed plus ADDing as many 
lines as necessary to complete the definition. Once all increments are defined, the Cl e rk 
clerk clicks on SET POLICY is selected in the message box to activate these 
5 values/increments in the bid processing. The serveF -Bid System 120 compares the value 
of the last accepted bid against these table values and generates the appropriate 
INCREMENT BID BARS for both the Clerk System 130 and Bidder D evice 110 
displays. This is done each time a bid is accepted fi'om the floor or from_a remote bidder. 
The process of updating Marquee System Device 108, Clerk System 130 and Bidder 
10 Device 110 displays is the same as the Cherokee Bid Engine with the calculations 
performed by the sew ^Bid System 120 p rior to the values being sent to the 
Displavs displays . 

^ OPERATION OF THE APACHE BID ENGINE 

The fourth Bid Engine utilized is Apache (or OGAC) . In this Bid Engine, bids are 
15 "ASKed'* for and then accepted ^ by the clerk. A number of the processes are equivalent to 
those previously described with minor variations. The format of the Marquee System 140 
and Bidder Device 1 10 displays is different from those referenced in prior sections. 
Figures 25A/25B/25C are sample Clerk System 130, Marquee System 140, and Bidder 
D evice 110 d isplays fi*om the Apache Bid Engine. 

20 ^ MARQUEE DISPLAY UPDATES 

¥he -Under the Apache Bid Engine operation, tlie M arquee System 140 display is 
updated for th e following actions in accordance with the aforementioned bid engines as 
well as the following : 

The NOW SELLING LOT NUMBER fi e ld is updatod wh o n tho clerk enters 
25 NEXT LOT. Tho field remains tho oamo until tho >JEXT LOT button is selected. 

Th e purpl e bar flash e s ( e .g., purpl e /gre e n) when a r e mot e bidder has mad e a bid. 
Th e flashing continues imtil th e clerk acc e pts th e bid valu e firom either a floor bidd e r or a 
r e mot e bidd e r. 
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REMOTE BID and REMOTE BID AMOUMT ar e updat e d when a remot e bid has 
b e en mad e . Th e s e fi e lds ar e cl e ared wh e n th e bid valu e is accept e d (eith e r floor or 
remot e ). 

HIGH BIDDER and LAST LOT SOLD are updated each time the clerk clicks on 
5 the SOLD button. The HIGH BIDDER contains either FLOOR or the remote user ID. 

The processes to update the Marquee System 140 are the same as those defined 
for the previous Bid Engines. The difference is the specific data elements and placement 
on the Display that vary betw e en among b id engines. 

CLERK DISPLAY UPDATES 

10 Under the Apache Bid Engine operation, the The cl e rk fimction Clerk System 130 

is fimctionally the same as that defmed for previous Bid Engines. The primary difference 
is that the elerie -Bid System 120 ASKS for a bid by oUclcing on w hen one of the BID 
INCREMENT BARS on the Clerk System 130 display is selected on the right side of the 
scr ee n . A bid for that value — once accepted by the auctioneer — is then entered by 

1 5 selecting is th e n accepted by th e cl e rk by cliclcing on either the FLOOR BID or 

REMOTE BID button at the top of th e on the Clerk System 130 display. As with the 
Cherokee, Mohawk and Iroquois bidding engines, variations of instructions can allow for 
streamlined operations by automating bid acceptance when a higher increment is 
selected. Actions taken/display updates for the clerk fimction occur £is follows: 

20 LOT NUMBER - updated when NEXT LOT is cUcked for the next sequential 

entry in the ringman inventory subset. 

BDDDER - updated when a bid is accepted, by the cl e rk. 

SOLD AT - updated when the clerk s e lects th e SOLD button is selected . 

ACTIVITY MESSAGES - updated each time an - Clerk System 130, Bidder 

25 Device 1 10 or Bid System 120 action is talc e n by e ither tho cleric or bidd e r processed . 
CHANGE BID - allows tho clerk to ent e r a valu e not shown on the BID 
INCREMENT BARS and to enter a starting bi d allows for a value not shown on the Bid 
Increment Bars to be entered, a starting bid to be entered and a previous bid to be 
modified . 

30 DELETE BED - deletes the last bid and resets to the bid prior to the last bid. 
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NEXT LOT - same as the NEXT ITEM function. 

REMOTE BID - clork solectG REMOTE BID m ay be selected to accept a bid 
from a remote bidder. 

FLOOR BED - clork o o l o otG FLOOR BED mav be selected to accept a bid from the 
5 live gallery. 

SOLD - clerk s e lects SOLD may be selected w h e n after the last bid has been 
accepted and the auctioneer identifies the item as sold to that bidder. When the eleffe 
clicks th e SOLD button is selected, a window is displayed on the Clerk Sefeen -System 
130 display for the purpose of clerk to enterinR the bidder number to whom the item was 
10 sold. This data is then placed in the activity messages - and sent to t he Marquee System 
Display Device 108t and the bottom of th e Bidder Device 110 displayS efeen. The 
processes for these functions are the same as the Iroquois Bid Engine with the following 
differences: 

The FLOOR BID button may be used to accept a bid is us e d instead of clicking 
1 5 on the BID INCREMENT BAR for that value. 

The BID INCREMENT BARS are used to broadcast a request for a bid rather 
than te-accept a floor or remote b id. 

Figure 26 illustrates an example of a Clerk S ystem 130 display-se reeH from the 
Apache Bid Engine. 

20 BIDDER DEVICE 110 DISPLAY UPDATES 

Under the Apache Bid Engine operation, U updates to the Bidder Sereen-Device 
110 display and functions activated by the bidder include: 

LOT # - updated each time NEXT LOT is selected, by the cl e rk. 

BIDDER/CURRENT BID - updated each time th e clork acc e pts the Bid System 
25 120 broadcasts that either a FLOOR or REMOTE BED has been accepted . 

BE) HISTORY - updated each time the bidder or clerk talces an aotion B id System 
120 broadcasts an action taken on a Bidder Device 110 or Clerk System 130 . 

BID STATUS - indicates status of the remote bid from this us e rt hat same remote 
bidden . 

30 YELLOW " PENDINGt^ bid has been selected by the bidder 
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GREEN - ACCEPTEDr^bid was accepted by the elet feauctioneer 

RED - OUTBIDrj:_the FLOOR or another remote bid was accepted for this 

value. 

PREVIOUS LOT #AVINNING BDDDER/WDSfNING BID AMOUNT^ - updated 
5 each time the clerk clicks th e SOLD button on the Clerk System 130 is selected . 

BED VALUE - updated each time the eleri eBid System 120 broadcasts a new 
ASKS value for a bid . The bidder clicks on this button to enter a bid. The button is cleared 
each time the SOLD button on the Clerk System 130 is selected by th e cl e rk and remains 
clear until the NEXT LOT first ASKing price is e nter e d bv the cler kb roadcast by the Bid 
10 System 120 . 

HELP - activates a new webpage with hints/FAQs for the bidder. Bidder retums 
to the normal bid -Bidder Device 110 display by clicking the X in the upper right comer 
of that webpage. 

Figure 26-27 illustrates an example of an updated Bidder Device 110 
15 Sscr ee n display . 

All ringman inventory subset data for the bidde^F -Bidder Device 110 display is 
generated at one time for the displa y presentation and placed to the right of on the Bidders 
D evice 110 d isplay. This area ts -may be scrollable and contains limit e d information for 
each lot being sold. The data is broadcast to the bidder when the logon sequence is 
20 completed. 

9 DATA MINING 

Upon completion of the auction, the bidders attendance log and the bid log are 
available for post processing fi-om the Bid System 120 directly or through a predefined 
UR fcnetwork address . The data is collected during the auction by the Bid System 120 as 
25 the events take place. 

The bidders attendance log n^tst -canb e downloaded directly fi-om the Bid System 
120. The bid log is- can be obtained by accessing the required URL -network address for 
that auction. Ar -In one embodiment, a script ts -can be executed that-to.extracts the data 
fi-om the Bid System 120 and places it en-at_the assigned website location . 
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94 SCRIPT PROCESS BIDDERS LOG 

¥he -More specifically, the Bid System 120 maintains a log of bidders who 
connect to each auction. The log entries are maintained in a table on the System with an 
entry being made each time a bidde rBidder Device 110. the Celer k System 130 , or the 
5 Marquee System 140 a fe-is initiated through the login process. Th e showlogins script 
e xtracts th e ddP ata can be extracted fi"om this table and ptaees -placed th e data on the 
s€fee fidisplay . To be initiated, tT his serip ^xtraction process may r equires a xmique 
logon/password combination to be entered on the Bid System 120. to b e initiated. The 
analysis of this data identifies the user logon ID and the period for which the user was 
10 connected to the Syst e m remote bidding system . 

9^3 SCRIPT PROCESS BID LOG 

The access to the bid log is -can be provided via a special website location 
specifically set up to extract the data fi-om the bid s e rv e r Bid System 120 . Th e URL for 
thi s process is 

15 http://onlineriDgman.com/cgi - bid/ringman/querv.cgi?bidlog,html+dbname - 

wh e r e "auction" i s a imiqu e nam e for e ach auction. 

Whei^ -In an exemplary embodiment? when the w e bsite location is accessed, the 
script initiated firom the website performs a database query to the Bid System 120 . The 

20 Bid System 120 extracts the log entries firom internal tables and places them in sequential 
time order on the websit e display. Automated analysis provides remote bidder 
information^ includin g but not limited to bids made per user ID, number of items 
purchased by user ID, time of sale, amount of sale, average $value of items sold to 
remote versus floor bidders, and total statistics for the auction. The analysis can be 

25 defined specifically for each auction fi*om the unique data items available. 

W AUDIOA^IDEO SYSTEM 

The audio/video system of the present invention ("AN -AA^ SubsS vstem") is a 
Client/Server audio and video transport system. It provides a streaming audio and video 
feed firom a customer site to client workstations that may be located anywhere on tiie-a 
30 global Int e m e t network . Clients receive the AA^ feeds using standard WWW b rowser 
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software and sound cards. The system may be used for standalone applications, or may be 
incorporated into interactive w e b -e nabl e d database applications as a functional subset. 
The AA^ Capture System 102 is used to (a) convert the signal from a video source to a 
digital stream, which can then be transmitted to the AJV System 100 on a continuous 
5 basis?: and fb) convert the signal from the sound source to a digital stream, which can 
then be transmitted to the AA^ System 100 on a continuous basis. The AA^ System 100 
broadcasts the received feed or feeds to the clients or Bidder Devices 110 with minimal 
delay. 



10 There are two overarching design elements that firmly define and delineate the 

xmique nature of the AA'^ System 100: - Gconnectionless - and N ^ mon -bBuffered 
Performanc e performance . Mass-market audio/video streaming applications are oriented 
towards delivery of content under the assumption that buffered delay is acceptable in 
order to ensure very high quality (CD-quality audio, picture-quality video) at the chent 

1 5 end of the application. vWhile appropriate for consumer and high-end business delivery 
(high bandwith or broadband) , this approach misses a potentially large audience that will 
trade a degree of final output quality for a more real-time performance experience (for 
example, to receive the "live" look and feel of an auction). These mass-market solutions 
are typically connection-oriented in their network delivery techniques. 

20 The AA" System 100 uses connectionless, non-buffered designs that, in spite of 

the implications of the terminology, delivery FM-quality (voice) audio and still video 
streams to remote clients while at the same time ensuring an interactive response 
tumaround from the chent application that allows the auctioneer to communicate with 
remote bidders without delaying or affecting the process or flow of the auction (typical 

25 delays are e f -approximately one second or less) . A bonus of this approach is that it 

fimctions quite well using the lowest common denominator of internet access transport at 
this time — the V.90 analog modem connection. As end-user coimection technology 
migrates to schemes with speeds higher than 56 Kbps (asynchronous) — for instance, to 
ADSL or cable modem technology — the performance inherent in the AA^ SubsS vstem 

30 design will already be guaranteed. 
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iOA — INNOVATIVE APPLICATION OF CURRENT AA^ TECHNOLOGIES 

The AA^ Subs Svstem provides its audio, video^ and integration services by using 
existing transport and display services in a completely imique manner. A standard audio 
encoding/decoding scheme is extended to ensure the reliable transmission of an FM- 
5 quality stream. A still video standard— JPEG — is sampled and streamed to simulate a 
live video feed while eliminating the overhead and bandwidth requirements that typically 
accompany such a configuration. And the final client-side presentation is integrated into 
s tandard WWW browser t e chnolog y the Bidder Device 110 display, removing the need 
for multiple or custom standalone audio/video applications on the r e mot e e nd of the 
10 s^vie aBidder Device 110 . 

— AA^ SYSTEM OVERVIEW 

When considering the development of a system that can deliver an audio and 
video feed firom an source s e rver location A A^ Capture System 102 to multiple 
eUent Bidder Device 110 - locations , with minimal delay, there is one critical architectural 
1 5 decision that must be investigatedT^that of selecting the €efe -core N etwork n etwork 
Topo lo g yt opolo gy . This decision not only drives the final system architecture, it also 
determines the audience and market scope that may be addressed by the final system. The 
Gcore Nnetwork Ttopology is, in short, the choice of a transport backbone over which 
captured audio and video streams will be processed and delivered to remote client 
20 applications. There are many choices for such a backbone, including: 

Private Broadcast/Multicast [Terrestrial or Satellite] Networks 

Proprietary [Branded] Internet Broadcast Channels and Software 

Custom Standards-Based Internet Software 

Of these topology choices, the first, like broadcast or cable television, would 
25 result in a system suited to content delivery on a large scale, but fi:om a practical 

standpoint unaffordable by small to m e dium busin e ss e s that wish e d to deliver content. 
The second, while less restrictive than the first, typically carri e s lic e nsing costs, co 
branding r e quir e ments, and is optimized for one-way content transport. Because the AA^ 
Subs Svstem 4-00- needs to interact with other interactive database and web solutions, 
30 custom development of the AA^ SubsS vstem -jrOO u sing Op e n Source, Open Systems 
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Standards was logical ly mandated .^ The A/VSubsSystem 400 is designed under the 
assumption that the majority of remote clients being served by an installation are 
connecting to the Intemet using V.90 (56K) modems or less . It is further assumed that, on 
average, a V.90 connection will receive roughly 40 Kbps of reUable bandwidth over time 
5 during a session. Using these assumptions, general design parameters may be defined for 
the audio and video streams that will be sent to client software Bidder Devices 110 by the 
AA^ System lOOs erveFr. 

lO.Ll AUDIO 

The audio stream must be structured such that it can maintain a voice-quality feed 
10 imder conditions that may include limited bandwidth (i.e. less than 56 Mbps sustained). 
In order to minimize development and^ hence, customer costs, the audio encoder and 
sewe ^server m usf can run in an Open Systems server environment, and the client 
application should require minimal development using off-the-shelf browser technology. 
The se l e cted p referred audio encoder/decoder utilizes the GSM 06.10 codec 
15 library. The streaming audio produced by this library utilizes 13,3 Kbps of bandwidth and 
delivers an 8 KHz voice-quahty audio signal to the Bidder Device llO. r e mot e bidder 
cli e nt macliine's sound card. 

10.1.2 VIDEO 

Requirements for the video stream are the same as those outlined above for audio, 
20 with one subtle difference. While the preferred long-range architecture of the AA^ 

SubsS vstem 100 should not, and does not^ preclude the inclusion of non-lossy or full- 
motion video technologyti initial design requirements are such that video need not be 
completely full-motion. A rate of one fi-ame per three seconds has been set as a 
reasonable benchmark for the current release of the AfV SubsS vstem -400 . It is expected, 
25 however, that with the emergence and subsequent adapation of higher bandwidth 

technology and devices (e.g. cable modems, DSL, etc.), the AA^ Subsvstem will be able 
to advantageously utilize the increased bandwidth and provide a video signal with a 
firame rate that approaches non-lossy or full motion video. 

The vid e o e ncod e r AA^ Capture System 102 utilizes JPEG for video software, and 
30 the streamer portion of the server is designed to give priority, should it be required, to the 
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audio feed. The combination of the audio and video stream to any given remot e bidd e r 
el iBidder Device ea t 110 will, under normal network conditions, fit into the 40 Kbps 
average ceiling estimated for V.90 connections. 

The AA^ System 100 AA^ Subsvstem is composed of hardware and software 
5 elements configured in a client/server architecture. The AA^ Subsystem -consists of 
s e rv e r sid e of th e AN AA^ System 100 is confi jgur e d to run in th e Linux Op e rating 

Syst e m e nvironm e nt, and consiGts of an Encoding Server the AA^ Capture System 102 

(typically deployed at the site of audio/video capture) and a Master Serve r or Reflector — 
the AA^ System 100 (maintained at a s e cure high capacity AMS Point of Presence) . The 

10 Encoding S e rv e r AA^ Capture System 102 sends an single-audio and video stream to the 
AA^ System lOO Mast e r S e rv e r , which in turn oversees distribution of multiple streams to 
the remote chents. The client side or Bidder Device 110 of the AA^ System tOQ- is 
typically configured to run with standard commercial WWW/HTML browsers . In one 
embodiment, ; cun' e ntly the client is -can be deployed specifically for the Netscape™ 4.X 

15 browser release, but the architecture does not preclude compiling for Microsoft Intemet 
Explorer™ or other browsers. 

Figures 28 and 29 present general views of the layout and operation of the AA^ 
SubsSystem. 

iOrS — ENCODING SERVER - FUNCTIONAL 
. 20 The AA^ Capture System 4^102 Encoding S e rver runs imdor Linux and us e s th e 

Ospr e y 100 vid e o captur e card (with th e BTTV driv e r for Linux) for vid e o captur e . A 
Linux compatibl e 16 bit sound card ( e .g. SB 16, SB32, ESS, e tc) is r e quir e d for audio 
capture. Th e e ncod e r opens up two connections to the Mast e r S e w e r S e rv er AA^ System 
100 — one for a video stream and one for an audio stream. The video is compressed into a 
25 full JPEG image and is sent at a steady rate, determined at server connection. The audio 
is compressed using GSM 06.10 standard encoding/decoding algorithms and is sent at a 
steady rate, also determined at sefv ^he AA^ System 100 connection. 

The AA^ Capture System 102 at initiation of the streamer can accept several 
parameters that invoke the following features: 
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Dual Modems - for dual modem configurations, it is desirable to select one 
modem for audio and the other for video. Doing so will require proper setup of the 
routing tables. 

Save To A File - The AA^ Capture System 102 will encode the captured audio 
5 and video; however, rather than send it to the AA^ System 100, the resulting captured 
audio and video will be saved to a file. 

Play From A File - The AA^ Capture System 102 will use encoded source 
material and stream it to the AA^ System 100 rather than receive the input fi"om the Video 
Source 104. 

10 Frequency - This parameter will change the frequency in which the AA^ Capture 

System 102 captures or encodes a frame. 

Quality - This parameter will change the quahty of the encoded video. 

The e ncod e r uses a configuration fil e "ams str e amer.conf " which is in th e foniiat 

15 ID Ger\ ' er port audio int e rfac e video interface ser\^ e r addr e ss password 

Only the first lin e of th e fil e will b e r e ad; all oth e r lin e s ar e ignor e d. 

Valid configurations include: 

123 9781 192.168.1.1 password 

4 56 9782 pppOpppl 192.1 68.1.1 pw 
2:0 Note that the IP address used for the server - addres s field above is a dummy 

e xampl e only. 

Th e 123 configuration u ses " " (m e aning d e fault int e rfac e ) for both audio and 
video interfaces; th e 4 56 configuration us e s pppO for audio and pppl for video. For dual 
mod e m configurations (possibl e with multilinlc PPP configurations, but not 

25 recomm e nded by AMS), it is desirable to select on e modem to send audio and the other 
to s e nd vid e o. Doing so will requir e prop e r s e tup of th e routing tabl e s and root privil e g e s 
(to allow se l e ction of which interface to send the pack e ts through), and can b e don e by 
malcing th e e ncoder program setuid - root. 

Th e e ncoder is invok e d by numing stream e r from th e Linux command lin e . [Note 

30 In AA^ Transport v e rsion s to dat e th e re or e two other programs — stream e r save and 
str e am e r play both of which are curr e ntly for testing purpos e s only.] 
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The str e am e r program acc e pts/has the following command line optioiiG: 
stream e r f frequency q qualit>^ h 

The - f frequency option specifies th e frequ e ncy of vid e o captur e in tenth s of a 
second, with the d e fault set at 30. The - q quality option specifies th e JPEG compres s ion 
5 quality as a r e lativ e p e rcentag e b e tw ee n 1 and 100, wher e low e r numb e rs e quat e to lower 
image quality, with th e default s e t at 15. The - h option will display command lin e h e lp. 

iQA — ENCODI>JG SER\^R BUILD ENVIRONMENT 

The encoder runs under Linux and requires GNU make and GNU gcc. It uses the 
Independent JPEG Group^s (UG) JPEG sofaware (for vid e o), th e GSM 06.10 Ubrary by 
10 Jutta Degen e r and Carsten Bormann of Technisch e Universitaet Berlin (for audio), and 
th e MD5 messag e dig e st algorithm by RSA Data S e cuiiti e s, Inc. (for auth e ntication). 
The Build Environment specifics are: 
Operating System: Red Hat Linux 5.2 (or high e r) 
Linux Kem e l: 2.2.X (or high e r) 
15 Kemel Library: libc. s o.6 (or higher) 

Compiler: GNU C 2.7.2 (or higher) 

m5 — ENCODING SER\TBR HARDWARE El^^VIRONMENT 

Th e Encoding S e rv e r r e quires th e following hardwar e compon e nts: 
IBM compatible PC, Intel Pentium 450 MHz (or faster) CPU 
256 MB RAM (minimum) 
1.0 GB Hard Di s k (minimum) 
V.90 (56K) internal modem 
10/100 Ethern e t Network hit e rfac e Card 
Keyboard and Mous e 
Ospr e y 100 Vid e a Captur e Card 
15" CRT Display (.27 mm dot pitch) 

Sound card (SB 16 compatible) with sp e ak e rs and microphon e input 
CD ROM drive 
3.5" l.^^MB floppy driv e 

Vid e o Capture Devic e (S e nsomatic camera pref e rr e d) 
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Audio Lin e Mixer (Radio Shack recommeiided) 

A rout e d Int e rnet connection using a high capacity circuit t e chnology is 
suggested. (Singl e Hnlc analog PPP connectivity via the internal mod e m is possibl e , but 
not supported by AMS. Multilinlc analog PPP conn e ctivity via dualint e mal mod e ms is 
5 also possibl e , but again is not activ e ly support e d.) Th e Int e rn e t conn e ction may use any 
of s e v e ral availabl e connection t e chnologi e s, including but not limit e d to (a) dialup ISDN 
(128K dual chann e l), (b) dedicated ISDN (128K), (c) xDSL, (d) Fram e R e lay, or (e) 
d e dicat e d privato lino. 

— MASTER SERVE RA A^ SYSTEM 100 - FUNCTIONAL 

1 0 The Mast e r Serv e r AA^ System 100 accepts streams from Encoding Serv e r AA/^ 

Capture System 102 and sends them to Bidder Devices llOe lients. It supports multiple 
streams. Each stream4s - may be p rotected by a password to prevent unauthorized 
encoders from using the server. In a preferred embodiment of the present invention, W ith 
th e current impl e m e ntation, a stream is ready to send to clients when both the audio and 

15 video channels have been established. Ideally (given p erfect network conditions), packets 
are sent using the audio packets as the pulse (--200ms) and followed by a set video frame 
size. Audio and video are delivered to clients in a single channel to ensure more priority 
for the audio and to lessen the amount of buffering required for the audio. In a preferred 
embodiment, A udie -audio is not considered critical (lest- lost p ackets allowed) on both 

20 encoding and the client end. This is by design as the entire AA^ SubsSystem -tOO- is 
constructed for integration with interactive database appUcations (live auctions are a 
primary example). Under network congestion or error conditions^ the integrated 
application must receive higher network priority. 

In a preferred embodiment of the present invention, V video on the encoding end 

25 is not considered critical. However, video on the client end is considered critical (any 
missing parts will be re-requested until all parts are available; note that images that seem 
to be incomplete are due to the encoder, not the client). Remote bidder cUents will 
receive the most recent complete frame available on the server at the time of request. 
Currently, connections to streams do not have access controls to limit which connection 

30 can view which stream. 
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The s e rv e r use s a configuration fil e ams - sci-verxohf, which is in the format of: 
ID s e rver port str e am port password 

Multiple e ntrie s may b e sp e cifi e d to allow multipl e str e ams (th e maximuiD 
number of streams allowed is s e t up at program compil e time). Th e ID, serv e r port, and 
5 str e am - port must b e unique. [Not e : tli e curr e nt impl e m e ntation uses port 9780 for all 
s erv e r ports, r e gardless of the number sp e cifi e d.] 

Th e s e rv e r is invok e d by rimning s erver at th e Linux command line. Th e s erver 
process s hould b e left running whil e th e Master S e rv e r machin e is activ e . At this tim e th e 
server program has not b e en configured to run as a daemon process under the control of 
10 in e td. The server program s hould be run by a non root us e r. It is suggested that the scr e en 
program b e us e d to start th e server: 

$ screen ./ s ever 

This will allow th e program proc e ss to be d e tach e d fi-om the con s ol e or terminal 
s e ssion using th e k e y s e qu e nce Ctrl - A+D, Th e session may b e r e attach e d at a lat e r tim e 
15 with th e command: 

$ s creen r (pid) 

Where (pid) is the proces s ID of the s e rver program. 

if the server code was compiled with "TESTING" d e fined, th e command lin e " t 
clients" i s available for s tres s te s ting with "cUents" amount of fak e client s . 



The Mast e r S e rv e r r e quir e s GNU malce and GNU gee. It us e s th e MD5 m e ssag e 
digest algorithm by RSA Data S e curiti e s, Inc. for authentication. 
Th e Build Environment s p e cifics are: 
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K e rn e l Library: 
Compil e r: 



Op e rating Syst e m: 



Linux K e m e l: 



R e d Hat Linux 5.2 (or high e r) 
2.2>X(or higher) 
libc.ss.6 (or high e r) 
G>JUC 2.7.2 (or high e r) 



4-0t7 — MASTER SERVER HARDWARE ENVIRO>nVlENT 
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The Ma s ter Server requires the following hardware components: 
IBM compatible PC, "Ser\^er" Class 
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Dual Intel Pentium 1 H50 MHz (or fast e r) CPUs 

256 Nffi RAM (minimum) 

4 ,0 GB Hard Disk (minimum) 

100 Mbps Fast Ethemet Network Int e rface Card 

Keyboard and Mous e 

15" CRT Display (.27 mm dot pitch) 

CD ROM drive 

3.5" lAA MS floppy drive 



iOrS — CLIENT - FUNCTIONAL 

The preferred Bidder Device 100 client is a Netscape plug-in using Win32 code. 
It opens up a connection to the s e wer serv efAA^ System 100 and decodes the packets it 
receives into audio and video. The audio is played through the default Windows 
Operating System audio playback device. The video is displayed in the N e tscap e 
browser.^ager The client will try to maintain a constant three audio buff e rs frames for 
playback (- 70Oms 700ms) . If it has fewer, it will play the audio a bit slower; if it has 
more, it will cut off th e audio if ther e ar e too man y disconnect from the A/V System 100, 
or il^iLwill play the audio a bit faster to catch up. 

The chent must start with "np" and end with ".dll" and reside in Netscape's plug 
ins directory. 

The chent may be invok e d from an HTML page by using th e following: 
<ombcd src-192.168.1. 1:9873 width-256 hoight-192 typo-*'application/x mi s 
ams'^x/ e mb e d^ 

The src param e t e r should point to th e s e rv e r's IP addr e ss and th e str e am e r's port. 

— CLIENT BUILD E>JVIROmiENT 

The client run s imd e r N e tscape and Windows 9x/NT. It requires MS Visual C++ 
(load up the amscli e nt proj e ct and compile th e NS project; th e resulting npams.dll fil e 
from th e NS proj e ct is th e plugin to use). It us e s tli e Ind e p e ndent JPEG Group's (IJG) 
JPEG softv^^aro (for vid e o), th e GSM 06.10 library by Jutta D e g o n o r and Car s t e n 
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Bormann of Technisohe Universita e t Berlin (for audio), th e MD5 messag e dig e st 
algorithm by RSA Data S e curities, Inc. (for auth e ntication), and N e t s capes plug in SDK. 

Th e Build Environm e nt specifics ar e : 

Operating System: Window s 95/98/NT 
5 Compil e riMicrosoft Visual C i i curr e nt r e l e as e 

10.10 COMPONE>JT LICENSE IhJFORMATION 
GSM 06.1 OLIBRi\RY: 

Copyright 1992,1993,1994 by Jutta Deg e ner and Carst e n Bomann, Technisch e 
Univ e rsitaet Berlin 

10 JPEG LIBRARY: 

This softwar e is cop>Tight (C) 1991 1 998, Thomas G. Lane. 

^tD5 LIBR.\RY: 

Copyright (6) 1991 2, RSA Data Security, Inc. Created 199L All riglits reserved. 
It i s believed tliat the following unique attribut e s distinguish the AA^ System from 
15 oth e r curr e ntly availabl e Internet - bas e d audio/video transmission syst e ms. 

10.11 ENGINEERING DESIGN 

iQAiA SPECIFIC VS. MASS MARKET DESIGN 

Other AA^ products are designed for very specific market applications, and the 
underlying architecture tends to be reflected in the final design, customer implementation 
costs, and (often) brandtag requirements. These design categories include 0neone-to-one 
Transpor t transport, €tfeup -group Collaboration collaboration Transport transport, and 
Qneone-to-M^Py ^manv ^ transport. Products like IP-Phone packages and online meeting 
tools exemplify the first two categories. These products tend to b e low cost (oft e n du e to 
branding/adv e rtising r e quir e m e nts), but ar e not to not be designed to scale well beyond 
point-to-point or small group usage. Most are, as well, audio-centric in their design. The 
third category is oriented towards broadcast or multicast to larger audience size, but 
products to date either tend ef-to focus- on delivery of pre— recorded content or, where 
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live delivery is concerned, involve extremely high^cost server and bandwidth 
configurations, that k e ep the tools out of r e ach for s mall to m e dium siz e d busin es s e s. 
(Co - branding is sometim e s used as a way to all e viat e costs, but many firms that would 
like to us e audio/vid e o transport solutions are r e luctant to ent e r co - branding or 
5 adv e rtising orient e d agr e em e nts.) 

Th e AA^ Syst e m 100 , while scalabl e for very larg e installations, was design e d 
with th e small to m e dium size mark e t in mind. The pric e p e rformanc e profil e for th e 
System is, th e n, a uniqu e point of differentiation in th e marketplac e . 
10.1L2 CODEC AND TRANSPORT SELECTION 

10 If an audio/video system is engineered to deliver audio at CD-quality levels^ and 

video at good approximations of broadcast-quality (or at least moderate video- 
conferencing quality), it will be engineered with codec and transport mechanisms that are 
"highly reliable" and that-tend to use some form of carefiiUy designed buffering for 
incoming streams to the client application. The term "highly reliable^" however, should 

1 5 not be taken to infer that a design lasing -using "less reliable" delivery mechanisms or 
"lossy" codec schemes is^ as a result^ a less robust design. The AN -A/V SubsS ystem -tOO 
was initially designed to deliver the "look and feel" of a live aute-auction to m onlin e 
Internet based remote audience, and the codec and transport design decisions reflect the 
unique requirements of this market. 

20 In a live aute-auction, there is an inherent degree of "noise" as a part of the 

process itself; product is rolled through the auction lan e at a rate no slower than one 
v e hicl e item every three minutes, and bidders have had time prior to the actual sale to 
investigate and inspect the v e hicl e s items . During the live sale process, a bidder is highly 
likely to focus on the progress of a particular bid by mentally parsing the increasing bid 

25 nimibers from the rapid pace of the auctioneer's patte rchatter . Under such conditions^ the 
"audio and video stream quality" become secondary considerations. When moving such 
an experience to an Int e rn e t bas e d remote environment, the AA^ Subs System iQQ 
engineering design is allowed to reflect these same conditions, hence the fact that AA^ 
System 100 delivers audio and video streams, but not in such a maimer that they would 

30 interfere with the ability of the remote bidder client to see the bid progress (in this case, 
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via a database update sent to the browser from a bid sewe r the Bid System) and act 
accordingly (by entering a remote bid, for instance). 

The encoding/decoding algorithm GSM 06.1 0 codec is -lossy.- It will not 
reproduce CD-quality audio but, given the design and market requirements, does not need 
5 to for the AA^ SubsSystem to function properly. The quality and frequency settings of the 
JPEG encoder, and the transmission/retry mechanisms built into the Encoding Serv e r's 
str e am e r AA^ Capture System 102, do not reproduce a broadcast-quality video signal but, 
once again, do not need to do so. In consideration of marketplace drivers and 
requirements for integration with larger system designs, the codec and transport design of 
10 the AA^ SubsS vstem represents a unique solution. 

10.11.3 STREAM PRIORITIZATION 

A follow-on to the fimdamental idea of codec and transport selection is the overall 
design of stream prioritization within the AA^ SubsS vstem -4-00 . Working with an 
estimated average bandwidth of 40 Kbps, the str e amer AA^ Capture System 102 software 

15 itself is written so that packets from the encoder's GSM stream will receive consistent 
priority and handling xmless video is available for processing. On the client side, the 
brows e r applet s idder Device 110 is programmed to follow these same rules, except it is 
also configured to look for packets from a separate bid s e rve r Bid System 120 (under the 
assumption that AA^ Transport is installed as a turnkey live auction solution)7-}L3^if it 

20 sees these packets , it is to give them priority over both audio and video streams. 

U PLATFORM I>JTEGRATION 

4-1.4 — SOFTWARE & HARDWARE PLATFORM SELECTION 

The A/V Syst e m i s design e d to support several unique market nich e s, and th e 
softwar e d es ign and op e ration (as discussed above) r e flect this philosophy. How e v e r, th e 
25 Syst e m is also e ngme e r e d to b e fl e xibl e and e xtensible should custom impl e mentation 
opportuniti e s pr e s e nt th e ms e lv e s. In ord e r to ensure that dev e lop e rs are abl e to r e spond to 
rapidly changing conditions both in terns of int e m e t topology or services and in t e rm s-ef 
mark e t d e mand, the bulk of th e softwar e platform upon which AA^ Syst e m is constructed 
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relies on highly available "Open Source" op e rating Gystem e nvironments and languag e 
toolkits. 

Similarly, th e soloction of hardwar e compon e nts wa s focus e d on th e IBM/Int e l 
compatible market on th o assumption that the best overall cost e ffici e nci e s for small to 
5 m e dium sized environm e nts is to be found with this type of equipment. Th e s e rv e r 
softwar e ( e ncod e r and main soiv e r) may b e port e d to mor e proprietary e nvironments if 
need e d (Sun hardwar e and tho Solaris OS, for e xampl e s), but to dat e th e mor e op e n 
platform has prov e n quite satisfactory in t e rms of handling custom e r load. Th e softwar e 
and hardware platform flexibility, however, s hould be noted as contributing to the uniqu e 
10 nature of the A/V System of the present invention. 
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REMOTE BIDDING SUPPLEMENT FOR 
TRADITIONAL LIVE AUCTIONS 



ABSTRACT 

A remote bidding supplement for traditional-style live auctions, comprising an 
5 audio/video system for streaming instantaneously and buffer- free live audio and video 
data from a live auction site to one or more remote auction bidders having a bidding 
device for receiving the data and for transmitting instantaneously remote auction bids for 
each item being auctioned at the live auction site; a clerk system for controlling and 
accepting auction bids received at the live auction site from onsite auction bidder and 

10 from remote auction bidders for each item being auctioned at the live auction site; a 
marquee system for displaying instantaneously at the live auction site auction bid 
information, including accepted auction bids, for each item being auctioned at the live 
auction site; and a bid system for broadcasting instantaneously to all remote auction 
bidders and to the marquee system the auction bid information for each item being 

15 auctioned at the live auction site, for receiving instantaneously auction bids from each 
remote auction bidder for each item being auctioned at the live auction site and for 
transmitting instantaneously to the clerk system each remote auction bid received for 
each item being auctioned at the live auction, and for broadcasting instantaneously to all 
remote auction bidders and to the marquee system the onsite and remote auction bids that 

20 have been accepted by the clerk system. 
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